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Vorwort 


Über vier Jahre sind vergangen, seitdem die erste Auflage des Profibuchs erschienen ist. In 
der Zwischenzeit hat sich vieles bei Hardware (MEGA ST, STE, MEGA STE, TT, Stacy, 
SCSI-Festplatten) und Software (neue TOS-Versionen, XCONTROL) getan. Auch über viele 
betriebssysteminteme Zusammenhänge wissen wir heute mehr als damals. Alle diese neuen 
Informationen haben wir in diese komplette Überarbeitung einfließen lassen. 

Wie Sie sehen, haben wir dabei nunmehr das maximale Fassungsvermögen für ein einzelnes 
Buch erreicht. Mit künftigen Weiterentwicklungen - ob beim Betriebssystem (Multitasking?) 
oder bei der Hardware (ST-Book, 68040-Rechner) - werden wir uns daher voraussichtlich zu 
einem späteren Zeitpunkt in einem Ergänzungsband befassen. 

Im vorliegenden Band sind wir unserem Motto treu geblieben, Fakten möglichst vollständig, 
aktuell, übersichtlich, präzise und preisgünstig zu präsentieren. Wir hoffen, daß Sie mit dem 
Ergebnis zufrieden sind. 

Münster, im Oktober 1991 

Hans-Dieter Jankowski, Dietmar Rabich und Julian Reschke 

Elektronische Mail kann an folgende Adressen gerichtet werden: 

Hardware: Hans-Dieter_Jankowski@ un.maus.de 

Software: Dietmar_Rabich@do.maus.de 

Julian_Reschke@ms.maus.de 


Hans-Dieter Jankowski 

Nach nicht unerheblichem Arbeitsaufwand ist es endlich geschafft! Die Hardware-Kapitel 
zum ATARI ST/STE/TT Profibuch sind endlich fertig. Nach Erscheinen der ersten Auflage 
des ATARI ST Profibuchs hat sich ja doch einiges auf dem Hardware-Sektor bei Atari getan. 
So ist denn auch einiges an Informationen zusammengekommen, das hier niedergelegt wurde. 
Wie immer hat “unsereiner” sich mal wieder bezüglich des dazu erforderlichen Zeitaufwandes 
um ca. 300 Prozent verschätzt, aber dennoch: Es ist vollbracht! 

“Unsereiner” ist jetzt Mitte 30, heißt Hans-Dieter Jankowski und ist von Beruf immer noch 
Ingenieur für Nachrichtentechnik. Während des Studiums in den Jahren 1974 bis 1977 ist 
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“unsereiner” kaum von der Datenverarbeitung “berührt” worden (eher abgeschreckt durch die 
Praktika an der DV-Anlage in unserer Hochschule, welche mit Lochkarten und in “PROSA 
300” - ist auch eine Programmiersprache, wenn ich mich noch recht erinnere - programmiert 
wurde). 

Nach dem Einstieg mit programmierbaren Taschenrechnern um 1979, mit ersten Erfolgs¬ 
erlebnissen in Form von selbsterstellten Programmen, erfolgte ein Wechsel auf einen “echten” 
Homecomputer mit Z80-CPU, 16 KByte RAM und Kassettenrekorder als “Massenspeicher” 
(vielleicht erinnnert sich ja der eine oder andere Leser noch an das “Video Genie”-System). 
Dann mußte Grafik und am besten auch Farbe her. Das führte zur Anschaffung eines “DAI”- 
Systems (8080 CPU, 48 KByte RAM und gute Farbgrafik-Eigenschaften), aber leider auch 
in eine Sackgasse. Es gab nur sehr wenige Anwender und kaum Software! 

Aber dann (um 1983) entdeckte “unsereiner” den ATARI 800XL und in diesem Zusammen¬ 
hang auch Julian Reschke (nein, nein, ich habe Julian Reschke nicht entdeckt , sondern 
lediglich kennen- und schätzengelemt!). Julian arbeitete ebenfalls auf einem 8-Bit-Atari und 
hatte schon bald Erfolge als Fachautor. Also warum nicht selbst einen Versuch starten; Ideen 
waren genug da. Zuerst kamen kleine Software-Tips, dann Utilities, die auch von den Verlagen 
angenommen wurden. Später kamen noch Erfahrungsberichte über Software dazu. 

Aber letztlich kann keiner gegen seine Natur und “unsereiner” nicht gegen seine Leidenschaft 
für die Hardware und damit das “Innenleben” der Ataris. Drucker- und sonstige Interfaces 
wurden gebaut und auch ein Cartridge-Experimentiersystem für die 8-Bit-ATARIs entwickelt 
(erschien mal im ATARI-Sonderheft von “Happy Computer”). 1986 kam dann der “Umstieg” 
auf den ersten 16-Bit-Computer (520ST+) von Atari. Begeistert von der Bedienungs¬ 
freundlichkeit (erster Gedanke: Ein tolles Ding, diese Maus; zweiter Gedanke: Wie die wohl 
von innen aussieht?) und der großartigen Bildschirmdarstellung (erster Gedanke: Das Bild 
flimmert ja gar nicht; zweiter Gedanke: Da müßte man doch mal das Videosignal unter¬ 
suchen), verschlang “unsereiner” alles, was an Informationen zu bekommen war. Besonders 
die Hardware interessierte natürlich, aber da waren die Infos doch sehr spärlich. Letztlich 
führte diese Leidenschaft dann dazu, die Kenntnisse über die Hardware der ST-Computer in 
einem Buch mit konzentrierten Infos über die Betriebssystemsoftware zusammenzufassen, 
und so wurde das ATARI ST Profibuch (Idee: Julian Reschke) “geboren”. 

Nachdem Atari nun im Herbst ’90 mit der neuen Rechnergeneration TT auf dem Markt 
erschien, wurde natürlich auch eine Überarbeitung des “Profibuchs” erforderlich. Wobei wir 
aber ganz schnell zu dem Ergebnis kamen, daß es mit einigen weiteren Anhängen nicht getan 
sein würde. Also mußte ein komplettes, neues Buch her, mit natürlich bereits im ST Profibuch 
enthaltenen Infos, aber eben auch einer ganzen Menge an neuen Daten über den TT/STE. 
(Wenn wir noch lange warten, müssen wir den Umfang des Buches noch weiter “aufblasen”, 
um auch den STBook und STPad mit aufzunehmen, ganz zu schweigen von Gerüchten um 
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ein Multitasking-TOS! Das führt dann letztlich dazu, daß dieses Buch nie erscheint, weil 
immer was Neues dazukommt.) 

Nachdem der TT dann endlich für Entwickler lieferbar war (also wurde ich schnell “Ent¬ 
wickler”, denn schließlich sollte man so ein Gerät, über dessen Innenleben man zu schreiben 
gedenkt, schon besitzen!), wurde auf dem schnellsten Wege ein Tr geordert. Dank Herrn 
Henseleits Einsatz (Dank, Dank, Dank!) von Atari-Deutschland kam “mein” Exemplar auch 
sehr schnell. Karton aufgemacht, und “Überraschung!”: Es war scheinbar ein Bausatz, denn 
alle Komponenten (ST-RAM-Erweiterung, FAST-RAM usw.) waren separat geliefert wor¬ 
den. Der nette Kommentar von Herrn Henseleit dazu: “Sie wollen ja das “Ding” sowieso aus- 
einandemehmen! Wir hatten es hier im Dauertest und haben es, da Sie es ja schnell haben 
wollten, sofort zerlegt versendet.” 

Aber nun genug der Historie und Philosophiererei! Ein besonders großes Dankeschön geht 
natürlich noch an meine Frau Marianne. Sie hat es nicht immer leicht gehabt, mich aus dem 
Innenleben der Rechner und Peripherie und dem Gewirr von Meßleitungen von Oszilloskop 
und Logikanalyzer (Originalton: “Mein Gott, hoffentlich kriegst du den (gemeint war der 
zerlegte ST) noch einmal wieder zusammen! ”) herauszulösen. Verbunden ist damit auch eine 
Bitte um Entschuldigung an sie und den Rest der Familie (inzwischen drei prächtige Ausgaben 
“selbstgemachter Hardware” männlichen Geschlechts, acht Monate, acht und zehn Jahre alt 
und mit gesunder “natürlicher Intelligenz” ausgestattet. Der Jüngste heißt übrigens auch Ju¬ 
lian, mal sehen, ob es was nützt!) für die viele Zeit, die ich statt mit ihnen an den Computern 
(vor allen Dingen bei der Erstellung des Buches) verbracht habe. Nachdem das Manuskript 
des Hardware-Teils nun fertig ist, verspreche ich, mich mehr um sie (die Familie) zu kümmern 
(hm, da war doch noch was von wegen Harddisktreiber usw...). 

Ein weiteres Dankeschön an Herrn Henseleit und Herrn Jurkat von Atari-Deutschland, die für 
mich immer ein offenes Ohr und reichlich Informationen hatten. 


Dietmar Rabich 

Als im Jahre 1962 eine Computergeneration begann, erblickte auch ich das Licht der Welt. 
Nach den vielen Jahren der Schule und einem Studium der Mathematik und Physik gehe ich 
seit 1989 als Diplom-Mathematiker dem Beruf eines Programmierers in einem großen Kon¬ 
zern in Dortmund nach. 

Der erste Kontakt mit einem Computer ergab sich im neunten Schuljahr. Auf einem Wang 
2200 mit 4 (vier) Kilobyte Hauptspeicher, einer Schreibmaschine als Ausgabemedium und 
einem eingebauten Kassettenrecorder als Massenspeicher wurde eifrig mit der ganzen Klasse 
BASIC gelernt. Und, wie sollte es anders sein, gerade dieser Rechner übte einen so starken 
Reiz auf mich aus, daß ich mich nicht mehr davon lösen konnte. 
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Dem Wang folgte daheim ein vergleichsweise komfortabler Rechner: ein CBM 3032 mit 32 
KByte RAM und zwei Diskettenlaufwerken. Auch hier hieß die Stammprogrammiersprache 
BASIC. 

1983 kamen dann mit dem Studium andere Programmiersprachen hinzu (Pascal, ForTran 77, 
ForTran 200, PL/I, ...). Die Kenntnisse konnten jedoch nicht auf den heimischen Rechner 
übertragen werden, also war eine Vertiefung der Kenntnisse nicht möglich. 

In der Erwachsenenbildung war ich regelmäßig als Kursleiter tätig. Unterrichtet wurde fast 
ausschließlich BASIC auf Apple Ile- oder Toshiba 1500-Rechnem. Von 1989 an bot ich nur 
noch kleine Kurse an. 

Das Jahr 1986 brachte mir endlich einen komfortablen, preisgünstigen Rechner: den Atari ST! 
Nach einer kurzen Eingewöhnungsphase - die Maus war bis dahin ein unbekanntes Peri¬ 
pheriegerät gewesen - versuchte ich, meinen ersten ST (einen 520 ST+) erst noch in BASIC 
zu programmieren, was ich aber wegen der bekannten Qualitäten des damaligen BASIC 
schnell auf gab... Ich wechselte zu dem CCD-Pascal-Compiler. Der alte CBM geriet mit der 
Begeisterung für den ST schnell in Vergessenheit. 

Da neben dem BASIC noch ein LOGO ausgeliefert wurde, ergab sich die Gelegenheit, auch 
noch diese Programmiersprache zu erlernen. Doch trotz überaus interessanter Details konnte 
sich LOGO keinen Platz als Leib- und Magenprogrammiersprache ergattern. Der Interpreter 
war doch zu wenig leistungsfähig. 

Die Jahre gingen ins Land, der 520 ST+ wich einem MEGA ST2 mit Harddisk, und diesen 
ergänzt mittlerweile ein TT030/6. Pascal mußte Modula-2 weichen und Modula-2 wieder C, 
so daß ich heute fast nur noch in C programmiere und entwickle. C zeigte sich als zuverlässig, 
mit allen Eigenschaften einer modernen Programmiersprache und guter Code-Erzeugung aus¬ 
gerüstet. 

Über die Jahre erschienen auch einige Programme: die Mathematik-Bibliothek MATH ! TR 
bei Creative Computer Design, das Disk-Utility und der SIGNUM!-Manager bei Application 
Systems Heidelberg sowie ein paar kleine Utilities. Weitere Programme - zumeist Utilities 
wie DISKINFO - wurden als Sharewareprogramme realisiert und auch so vertrieben. Wenn 
der ST oder der TT gerade mal nicht zum Programmieren herhalten müssen, stehen sie für 
Textverarbeitungszwecke oder ein gutes Spiel bereit. 

An dieser Stelle möchte ich mich bei allen bedanken, die mich unterstützt haben und mir das 
Hobby und den Beruf, der in die gleiche Richtung geht - jedoch keine Atari ST/TT- 
Programmierung, sondern eher Anwendungsprogrammierung unter Betriebssystem OS/2 und 
dem Großrechnerbetriebssystem MVS -, ermöglicht haben. 
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Ein besonders herzliches Dankeschön möchte ich auch an meine geduldige Frau Heike rich¬ 
ten, die mich nur allzu oft am Rechner vorfindet, ständig für mich Korrektur liest und immer 
Verständnis für meine zeitraubende Beschäftigung zeigt. 

Julian F. Reschke 

Geboren 1965 in Bremen, war ich noch gerade rechtzeitig dabei, um den Beginn der Compu¬ 
ter-Revolution im Heimbereich mitzuerleben. Nachdem programmierbare Taschenrechner 
(wer erinnert sich noch an das HI-LO-Game auf dem TI 57?) ihren ersten Reiz verloren hatten, 
mußte ein “richtiger” Computer her. Es machten aber nicht etwa ein Tandy, ein Apple oder 
ei n AIM das Rennen, sondern es war ein Sinclair ZX81, den man zum Schleuderpreis von 648 
Mark mit sage und schreibe 16 KByte RAM bekam. Das war im Herbst 1981. Doch schon ein 
knappes halbes Jahr später hatte die Computeszene ihren neuen Star: den Atari 800. Mit 256 
Farben, vier Tonkanälen, einem vernünftigen Betriebssystem und- natürlich - phantastischen 
Spielen (Ballblazer-Fans, hört Ihr mich?) war der Heimcomputer von heute geboren. Daß er 
mit 48 KByte RAM und einem Diskettenlaufwerk mit 90 KByte Speicherkapazität die unge¬ 
heure Summe von 3200 Mark kostete, konnte mich nur kurz aufhalten. 

Verschiedene Programme wurden fertiggestellt und mit unterschiedlichem Erfolg verkauft 
(“HIGHWAY DUEL”, “NADRAL” und “MEMO-BOX”). Letztes Projekt war das “ATARI 
Profibuch”, in das ich meine langjährigen Erfahrungen mit dieser Rechnergeneration ein¬ 
fließen ließ. 

Zum passenden Zeitpunkt betrat der Atari ST die Szene - nachdem die 8-Bitter von Atari aus¬ 
gelotet waren, gab es wieder viel zu entdecken. Wegen meines Studiums der Mathematik und 
Informatik an der Westfälischen Wilhelms-Universität Münster mußten die Erkundungsreisen 
in die Tiefen des ST jedoch in erster Linie in den Semesterferien stattfinden. Doch im Herbst 
1987 war es dann soweit- mit dem “ATARI ST Profibuch” erschien gewissermaßen der Urahn 
des nun vorliegenden Buchs. 

Seit Januar 1988 erscheint im “ST-Magazin” eine monatliche Kolumne, in der ich über die 
neuesten Entwicklungen bei der TOS-Programmierung berichte. Dort werden auch Korrek¬ 
turen und Ergänzungen zu diesem Werk zuerst erscheinen. 

Neben vielerlei kleinen Hilfsprogrammen (wie “BigScreen”, siehe Anhang) entstanden einige 
Libraries (wie die “FlyDials”) sowie die Festplattensoftware “SCSI-Tool” (Hard & Soft) und 
etliche Neuauflagen des “ATARI ST Profibuchs”. Als Haupt-Entwicklungssprache findet 
ANSI-C Verwendung - keine andere für TOS erhältliche Hochsprache ist vergleichbar ausge¬ 
reift und verfügt über ebenso umfangreiche wie standardisierte Bibliotheken - sehr wichtig 
bei Softwareportierungen. Assembler zu verstehen bleibt bei der Fehlersuche dennoch nütz¬ 
lich. 
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Mittlerweile steht ein TT030/6 mit Großbildschirm auf dem Tisch - Arbeitsgeschwindigkeit 
und Bildschirmformat sind eine Riesenerleichterung gegenüber früheren Tagen. 

Ich bedanke mich bei allen denen, die ich durch das gemeinsame Hobby kennengelemt habe 
und die mich mit ihrem Know-how unterstützt haben. Stellvertretend für viele seien da nur 
Amd Beißner, Stefan Eissing und Gereon Steffens genannt. Auch alle Kollegen “vom Fach” 
und die Atari-Mitarbeiter in Raunheim (Normen Kowalewski und seine Vorgänger) und Sun- 
nyvale (Leonard Tramiel, Bill Rehbock, Allan Pratt, Ken Badertscher und Mike Fulton) dür¬ 
fen sich angesprochen fühlen. Ebenso ein Hallo an die Redaktion des “ST-Magazins”, die sich 
Monat für Monat mit meiner “schweren Kost” beschäftigen darf. 

Schließlich noch ein Gruß an meine Freunde und Kommilitonen, die mich oft genug vom hei¬ 
mischen Bildschirm losgeeist haben, und ebenso an die Besatzung der Informatik der WWU, 
die ungeduldig auf die Ergebnisse gewisser objektorientierter Forschungen wartet. 
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Geleitwort zur TOS-Dokumentation 


Programmiersprachen 

Die folgenden Kapitel dokumentieren das “Application Programming Interface” (API) von 
TOS. Für fast alle Funktionen ist der entsprechende ANSI-C-Prototyp (also die Funk¬ 
tionsdeklaration) angegeben - meistens, aber nicht immer in Übereinstimmung mit den mit 
“Turbo C” mitgelieferten Bibliotheken. Änderungen haben wir genau dann vorgenommen, 
wenn die vorliegenden Bindings entweder falsch oder zumindest “unglücklich” abgefaßt 
waren. 

Natürlich ist durch die Angabe einer C-Funktionsdeklaration noch lange nicht die Parame¬ 
terübergabe geklärt. Daher finden Sie bei den BIOS-, XBIOS- und GEMDOS-Funktionen 
zusätzlich die genaue Stackbelegung und bei den GEM-Funktionen die Belegung der einzel¬ 
nen Ein- und Ausgabefelder. 

Damit sollte die Dokumentation auch für Benutzer anderer Hochsprachen oder Assembler 
möglich sein. Eine Kurzeinführung in die C-Syntax und die benutzten Datentypen, die natür¬ 
lich nur die allerwichtigsten Informationen aufführen kann, finden Sie im Anhang. Wir kön¬ 
nen jedem professionellen Entwickler die Benutzung eines ANSI-C-Systems nur ans Herz le¬ 
gen! 


Schichtenmodell 

TOS ist ziemlich sauber in mehrere Schichten gegliedert. Die folgenden Kapitel sind entspre¬ 
chend dieserHierarchie aufsteigend sortiert. Einige Faustregeln zur sauberenProgrammierung 
lauten: 

1. Niemals für eine Aufgabe Aufrufe verschiedener Betriebssystemschichten vermischen. 
Beispiel: In einem GEM-Programm fragt man Maus und Tastatur per AES, nicht etwa 
per BIOS, ab. Alles andere kann zu Konflikten zwischen den verschiedenen Schichten 
(hier: Tastenpufferung) führen. 

2. Niemals von irgendwelchen unsicheren Annahmen über interne Zusammenhänge zwi¬ 
schen den einzelnen Schichten ausgehen. Beispiel: Ein GEMDOS-Laufwerk kann 
sowohl auf einem BIOS- als auch auf einem Meta-DOS-Gerät liegen. Die Maus hängt 
normalerweise am EKBD-Chip, muß es aber nicht (externe Tastaturinterfaces, neue 
Hardware von Atari). 
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3. Immer nach Möglichkeit die höchste Betriebssystemschicht benutzen. 

Beispiel: Ein XControl-Modul kann die Länderkennung aus dem Betriebssystemheader 
extrahieren - besser aber ist es, dazu die entsprechende XControl-Datenstruktur zu 
bemühen. 


Dokumentiert oder nicht dokumentiert? 

Wir haben uns bemüht, immer möglichst präzise das wiederzugeben, was die Origmaldokumen¬ 
tation von Atari beschreibt. Leider war das nicht immer möglich: 

- Manche Funktionen sind in der Originaldokumentation offensichtlich falsch beschrie¬ 
ben; einige Dinge sind in verschiedenen Originaltexten widersprüchlich dokumentiert. 

- Manche Funktionen sind dort entweder gar nicht oder unvollständig beschrieben; in sol¬ 
chen Fällen haben wir unsere eigenen Erkenntnisse wiedergegeben und diese als solche 
gekennzeichnet. 

Für die Korrektheit unserer Beschreibungen können wir natürlich keinerlei Gewähr überneh¬ 
men. Ferner kann ein Buch natürlich niemals genauso aktuell wie die offizielle Dokumenta¬ 
tion des Herstellers sein. Jeder professionelle Softwareentwickler sollte sich daher auch bei 
der entsprechenden Atari-Niederlassung als Entwickler registrieren lassen, um neben diesem 
Buch auch die Originaldokumentation und den Entwicklersupport in Anspruch nehmen zu 
können. 

Künftige Weiterentwicklungen werden entweder in ein überarbeitetes “Profibuch” oder einen 
Ergänzungsband Eingang finden. Stets aktuelle Informationen zu diesem Thema finden Sie 
in den diversen Fachzeitschriften, insbesondere in der monatlichen Kolumne “Atarium” im 
“ST-Magazin”. 



Teil I 



TOS - Das Betriebssystem des Atari 
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Kapitel 1: BIOS und XBIOS 

Einleitung 

BIOS und XBIOS sind enge Verwandte. Sie sind in der gleichen “Betriebssystemschicht” 
angeordnet und teilen sich sogar denselben TRAP-Dispatcher. 

Das BIOS (“Basic Input/Output System”) ist das Bindeglied zwischen GEMDOS und 
Hardware (im “Bitchhiker’s Guide to the BIOS” ist das entsprechende Kapitel nicht umsonst 
“GEMDOS BIOS Calls” betitelt). Dazu stellt es Funktionen zur zeichenorientierten und 
blockorientierten Kommunikation, zur Speicherverwaltung und für den Zugriff auf System¬ 
vektoren zu Verfügung. Bis auf einige wenige Ausnahmen (bei der Behandlung der Zeitfunk¬ 
tionen) greift GEMDOS ausnahmslos auf BIOS-Funktionen zu. 

Insgesamt gilt die Faustregel: das BIOS ist für all das verantwortlich, was unterhalb der Ebene 
von GEMDOS und GEM stattfindet und nichts mit dem XBIOS zu tun hat - beispielsweise 
auch die Systeminitialisierung. 

Das XBIOS (“eXtended BIOS”) hingegen enthält eine große Anzahl hardwareabhängiger 
Erweiterungen-meist vollständig unabhängig von anderen Betriebssystemschichten. Faustregel 
sollte sein: XBIOS-Funktionen möglichst nur dann benutzen, wenn es keine Funktion einer 
“höheren” Betriebssystemschicht gibt, die man statt dessen benutzen könnte. 

- Viele der Funktionen dienen der Konfiguration von Hardware oder allerunterster 
Betriebssystem-Schichten. Gute Beispiele dafür sind “CursconfO” und “SetprtO”. Ein¬ 
stellungen dieser Art werden normalerweise vom Kontrollfeld vorgenommen, in eige¬ 
nen Programmen sollte man immer nur die Einstellungen abfragen. 

Funktionen wie “KbdvbaseO” sind eigentlich nur für residente Programme interessant. 

- Eine Funktion, die man in Anwendungsprogrammen braucht, ist “KeytblO”. Anders ist 
es nicht möglich, länderunabhängig Tastatur-Scancodes auszuwerten. 

- Die Grafikfunktionen sind Paradebeispiele für Funktionen, die man nicht in Anwen¬ 
dungsprogrammen einsetzen sollte. Grund: Sie sind nur für die ST-, STE- und TT- 
Grafikhardware definiert und funktionieren im allgemeinen für Grafikkarten nicht oder 
nur eingeschränkt. Das VDI-Konzepterlaubtprinzipiell Grafikkarten, deren Bildspeicher 
für die CPU überhaupt nicht zugänglich ist. Auch die Farbpaletten-Funktionen des 
XBIOS sind nur sehreingeschränktfür“farbigere”Grafikkarteneinsetzbar. Anwendungs¬ 
programme sollten daher ausschließlich GEM-Funktionen einsetzen. 



6 


ATARI Profibuch 


Zeichenorientierte Funktionen 

Welche Kanäle gibt es? 

Das BIOS kennt von Haus aus folgende sechs Ein- und Ausgabekanäle: 


Kanal 

Name 

Belegung 

0 

PRT 

Parallele Schnittstelle 

1 

AUX 

Serielle Schnittstelle 

2 

CON 

Konsole (Bildschirm mit VT52-Sequenzen) 

3 

MIDI 

MIDI-Schnittstelle 

4 

IKBD 

Intelligent Keyboard Processor 

5 

RAWCON 

Konsole (ohne Steuersequenzen) 


Auf neueren TOS-Versionen können über die XBIOS-Funktion “BconmapO” (siehe unten) 
weitere Kanäle installiert werden. Zur Bedienung dieser Kanäle bietet BIOS vier Ein- und 
Ausgabefunktionen: 


Name 

Funktion 

Bconstat() 

Status des Eingabegeräts feststellen 

Bconin() 

Zeichen einiesen 

Bconout() 

Zeichen ausgeben 

Bcostat() 

Status des Ausgabegeräts feststellen 


Vorsicht: für die Funktion “BcostatO” sind die Kanäle 3 und 4 vertauscht. 


Installation eigener Treiber 

Seit TOS 1.02 benutzt das BIOS eine dokumentierte Tabelle mit Zeigern auf die einzelnen 
Funktionen. Insgesamt gibt es Vektoren für acht Kanäle, doch nur sechs von ihnen können 
benutzt werden: 


Adresse 

Name 

Belegung 

$51E 

xconstat 

Acht Zeiger auf Eingabestatus-Routinen 

$53E 

xconin 

Acht Zeiger auf Eingabe-Routinen 

$55E 

xcostat 

Acht Zeiger auf Ausgabestatus-Routinen 

$57E 

xconout 

Acht Zeiger auf Ausgabe-Routinen 
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Wer eigene Routinen installieren möchte, sollte folgendes beachten: 

Die Funktionen werden mit den gleichen Parametern wie die entsprechenden BIOS-Funktio- 
nen aufgerufen (nur BIOS-Funktionsnummer und Kanalnummer fehlen). Der Return-Wert 
wird in Register DO zurückgeliefert. Alle Register dürfen benutzt werden, da der BIOS- 
Dispatcher selbst für das Retten und Wiederherstellen der “garantierten” Register sorgt. 

Ab TOS 2.00 werden die Gerätenummem über 5 (“RAWCON:”) mittels “BconmapO” 
verwaltet. Daher können die freien Einträge in den Systemvektoren - wenn überhaupt - nur 
unter älteren TOS-Versionen benutzt werden. 


Anmerkungen zu CON: und RAWCON: 

Der VT52-Emulator 

Beim ursprünglichen Entwurf des ST hat Atari deutlich in Richtung “Digital Equipment” 
geschielt und einige Anleihen beim verbreiteten Terminal “VT52” genommen. Davon ist 
nicht nur die Tastatur, sondern auch die für “CON:” benutzte Terminalemulation betroffen. 

Der große Vorteil liegt darin, daß genau diese Steuersequenzen auch auf vielen anderen 
Systemen benutzt werden. Gerade beim Anruf von Mailboxen mit Terminalemulation macht 
sich das positiv bemerkbar. 

Alle Steuersequenzen werden durch ESC (also den ASCH-Wert 27) eingeleitet. Daher nennt 
man sie auch (genau wie bei Druckern) üblicherweise Escape-Sequenzen. Dem ESC-Zeichen 
folgen eines oder auch mehrere Zeichen, die dann die eigentliche Funktion auslösen. 

Cursor up (VT52 ESC A) 

Bewegt den Cursor um eine Zeile nach oben. War der Cursor bereits in der obersten Zeile, 
passiert nichts. 

Cursor down (VT52 ESC B) 

Bewegt den Cursor um eine Zeile tiefer. War der Cursor bereits in der untersten Zeile, passiert 
nichts. 

Cursor forward (VT52 ESC C) 

Be wegt den Cursor um eine Position nach rechts, höchstens aber bis zum rechten Bildschirmrand. 


Cursor backward (VT52 ESC D) 

Bewegt den Cursor um eine Spalte nach links, höchstens aber bis zum linken B ildschirmrand. 
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Clear screen (and home Cursor) (VT52 ESC E) 

Löscht den gesamten Bildschirm und setzt den Cursor in die linke obere Ecke. 

Home Cursor (VT52 ESC H) 

Setzt den Cursor in die linke obere Ecke. 

Reverse Index (VT52 ESC 1) 

Bewegt den Cursor um eine Zeile nach oben. War der Cursor bereits in der obersten Zeile, wird 
oben eine Leerzeile eingefügt und der Rest des Bildschirms um eine Zeile nach unten 
verschoben. 

Erase to end ofpage (VT52 ESC J) 

Löscht ab der aktuellen Cursorposition (einschließlich) den gesamten Bildschirm. 

Clear to end ofline (VT52 ESC K) 

Löscht ab der aktuellen Cursorposition bis zum Ende der Zeile. 

Insert line (VT52 ESC L) 

Fügt an der aktuellen Cursorposition eine leere Zeile ein. Der Cursor wird an den Anfang dieser 
Zeile gesetzt und der Rest des Bildschirms um eine Zeile nach unten verschoben. 

Delete line (VT52 ESC M) 

Löscht die aktuelle Zeile und verschiebt den Rest des Bildschirms um eine Zeile nach oben. 
Dabei entsteht am unteren Rand eine leere Zeile. Der Cursor bleibt in der gleichen Zeile und 
wird an den linken Rand bewegt. 

Position Cursor (VT52 ESC Y) 

Positioniert den Cursor frei auf dem Bildschirm. Dazu übergibt man zusätzlich die gewünschte 
Y- und X-Position (Jeweils um 32 erhöht). 

Set foreground color (VT52 ESC b) 

Setzt die Schriftfarbe. Dazu übergibt man als zusätzlichen Wert die gewünschte Farbnummer 
(Anzahl der Farben vom Bildschirmmodus abhängig) als Byte (von dem nur die unteren vier 
Bits ausgewertet werden). 

Set baclcground color (VT52 ESC c) 

Setzt die Hintergrundfarbe. Dazu übergibt man als zusätzlichen Wert die gewünschte 
Farbnummer (Anzahl der verfügbaren Farben vom Bildschirmmodus abhängig). 

Erase beginning of display (VT52 ESC d) 

Löscht alle Zeichen zwischen dem Bildschirmanfang und der Cursorposition. 



BIOS und XBIOS 


9 


Enable Cursor (VT52 ESC e) 

Macht den Cursor sichtbar. 

Disable Cursor (VT52 ESC f) 

Macht den Cursor unsichtbar. 

Save Cursor position (VTS2 ESC j) 

Speichert intern die momentane Cursorposition. 

Restore Cursor position (VT52 ESC k) 

Setzt den Cursor wieder auf die mittels “Save Cursor” gespeicherte Position. Die dabei 
gesicherte Position wird gelöscht! 

Erase entire line (VT52 ESC l) 

Löscht die aktuelle Zeile und setzt den Cursor an den linken Bildschirmrand. 

Erase beginning of line (VT52 ESC o) 

Löscht alle Zeichen zwischen dem Zeilenanfang und der Cursorposition. 

Enter reverse video mode (VT52 ESC p) 

Schaltet für alle folgenden Bildschirmausgaben auf inverse Schrift (Vertauschen von Schrift- 
und Hintergrundfarbe). 

Exil reverse video mode (VTS2 ESC q) 

Schaltet wieder auf normale Bildschirmdarstellung um. 

Wrap at end of line (VT52 ESC v) 

In diesem Modus wird beim Erreichen des Zeilenendes automatisch die nächste Zeile 
begonnen. 

Discard at end of line (VT52 ESC w) 

In diesem Modus wird erst dann eine neue Zeile begonnen, wenn ein “Carriage Return” (13) 
und ein “Line Feed” (10) ausgegeben werden. 

Intern benutzt der VT52-Emulator die Systemvariablen “conterm” (diverse Einstellungen), 
“con_state” (wird bei der Umschaltung zwischen “normalen” Zeichen und Steuersequenzen 
benutzt) und “sav_row” (zum Speichern der Cursorposition bei ESC “j”). 

Laut “Hitchhiker’s Guide to the BIOS” ist allerdings nur die erste von ihnen offiziell 
dokumentiert! 
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Wie groß ist der Bildschirm? 

Von einem Programm, das VT52-Sequenzen für seinen Bildschiimaufbau benutzt, erwartet 
man zu Recht, daß es die gesamte verfügbare Fläche nutzt. Doch wie stellt man fest, wie viele 
Zeichen auf den Bildschirm passen? 

In der geringen Auflösung des ST könnten es gerade mal 25 * 40 sein, während auf dem TT 
in der hohen Auflösung beeindruckende 60 * 160 Zeichen Platz finden. Noch schwieriger wird 
es bei anderen Grafikkarten und erst recht dann, wenn ausgefeilte grafische Oberflächen TOS- 
Programme in Fenstern flexibler Größe ablaufen lassen. 

Leider gibt es keine Möglichkeit, den verfügbaren Platz abzufragen, ohne die Betriebssystem¬ 
schichten BIOS, XBIOS und GEMDOS zu verlassen. Daher sei an dieser Stelle folgender 
Vorschlag gemacht: falls die Environmentvariablen ROWS und COLUMNS existieren, dann 
enthalten sie die maximale Zeilen- bzw. Spaltenzahl. 

Vorteile dieses Verfahrens: 

- Es werden keine undokumentierten Betriebssystemeigenschaften benötigt. 

- Jede tastaturorientierte Shell (und an deren Anwenderkreis wendet sich ja dieser Vor¬ 
schlag) kann Environmentvariablen setzen. 

- Das Desktop “Gemini” bzw. die UNIX-Shell “Mupfel” nutzen diese Methode seit 
geraumer Zeit. 

Ausgaben ohne Terminalemulation 

Mit “RAWCON:” kann man alle Zeichen gewissennaßen ungefiltert auf dem Bildschirm 
ausgeben. Vorteile sind dahernichtnur der größere Zeichenvorrat(anstelle der Steuersequenzen), 
sondern auch eine deutlich höhere Ausgabegeschwindigkeit als bei “CON:”. 

BIOS- und VDI-Escapefunktionen 

Interessanterweise benutzen die VDI-Escapefunktionen des ROM-Bildschirmtreibers den 
gleichen Code und die gleichen Variablen wie der VT52-Emulator des BIOS. 

Dennoch sollte man innerhalb eines Programms keinesfalls beide Betriebssystemteile 
gemischt aufrufen. Der Grund: die BIOS-Ausgaberoutinen gehen ab TOS 1.02 über Vektor¬ 
tabellen und können damit umgelenkt werden. Die VT52~Escapefunktionen hingegen sind ein 
Teil des VDI-Bildschirmtreibers und könnten daher durch einen anderen Bildschirmtreiber 
ersetzt worden sein! 
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Benutzte Systemvariablen 

Über “conterm” kann man einige Attribute verstellen (Tastenklick, Tastenwiederholung, 
“Fing” bei Ausgabe von CTRL-G, Rückliefern von Scancodes bei “BconinO”). Ab TOS 1.06 
gibt es die zwei zusätzlichen Vektoren “bell_hook” und “kcl_hook”, über die man eigene 
Routinen für das “Ping”-Geräusch und den Tastenklick installieren kann. 

Über den Status der Umschalttasten wird in einer BlOS-internen Variable Buch geführt. Ihre 
Adresse ist eigentlich nur für Interruptroutinen interessant und kann mit Hilfe von “__sysbase” 
ermittelt werden. Andere Programme sollten statt dessen “Kbshift()” verwenden. 


Anmerkungen zu PRT: 

Auswahl parallel/seriell 

Die BIOS-Routinen zur Druckerausgabe geben normalerweise auf der parallelen Schnittstelle 
aus. “BconoutO” ist prinzipiell darauf vorbereitet, die Drucker-Voreinstellungen des XBIOS 
(“SetprtO”) in Hinsicht auf die zu benutzende Schnittstelle (parallel/seriell) zu berücksichti¬ 
gen. Leider ist die Abfrage in allen bekannten TOS-Versionen fehlerhaft, so daß Anwendungs¬ 
programme die Einstellungen selbst aus werten sollten (hinzu kommt, daß “BcostatO” die Ein¬ 
stellungen völlig ignoriert). 

Der DIABLO-Treiber 

Die Atari-Laserdrucker SLM 804 und 605 erfreuen sich aufgrund der hohen 
Ausgabegeschwindigkeit und des günstigen Preises großer Beliebtheit. Zum Lieferumfang 
gehört der DIABLO-Treiber, der sich auf BIOS-Ebene installiert und alle Ausgaben auf 
“PRT:” abfängt. Eine Liste der unterstützten Escape-Sequenzen findet sich im Original- 
Handbuch, so daß wir aus Platzgriinden an dieser Stelle auf einen Abdruck verzichten. 


Anmerkungen zu AUX: 

Die erweiterten seriellen Schnittstellen des TT (und Mega STE) haben natürlich auch 
Softwareprobleme aufgeworfen: sämtliche Programme gehen davon aus, daß BIOS-Kanal 1 
mit der seriellen Schnittstelle verbunden ist. Daneben war es bislang selbstverständlich, daß 
man die vom BIOS-Kanal 1 benutzte Hardware mit “Rsconf()” konfigurieren kann. Atari hat 
das Problem auf verschiedenen Ebenen gelöst. Zunächst einmal gibt es nun mehr als die 
bisherigen sechs BIOS-Kanäle. Je nach verwendeter Hardware kennt beispielsweise das TT- 
BIOS die folgenden neuen Geräte (die “erweiterten Gerätenummem”): 
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Kanal 

Belegung 

6 

ST-kompatible serielle Schnittstelle (“Modem 1”) 

7 

SCO Kanal B (“Modem 2”) 

8 

TTMFP-Schnittstelle (“Seriell 1”) 

9 

SCC Kanal A (“Seriell 2”) 


Nur die Belegung von Kanal 6 liegt als ST-kompatible serielle Schnittstelle fest Alle anderen 
sind von der verwendeten Hardware abhängig (wie viele es sind, kann man mit “BconmapO” 
abfragen). 

Kanal 1 ist nunmehr ein Platzhalter für “die” serielle Schnittstelle. Mittels “BconmapO” kann 
man ihm irgendeine der erweiterten Gerätenummem zuordnen. 

Dabei wird übrigens auch dafür gesorgt, daß bei der Umschaltung von Gerätenummer 1 die 
vier dazugehörigen BlOS-Systemvektoren angepaßt werden. 

Das “Seriell”-Modul des erweiterten Konirollfelds sorgt für eine entsprechende Initialisierung. 
Programme, die von den erweiterten Gerätenummem wissen, können natürlich auch über die 
BlOS-Zeichenausgaberoutinen auf die neuen Schnittstellen zugreifen. 

Warum “BconmapO” nun eine XBIOS- und nicht eine BIOS-Funktion ist? Legitimerweise 
gehen praktisch alle existierenden Programme davon aus, daß man mit “RsconfO” spezielle 
Eigenschaften von BIOS-Kanal 1 verändern kann. 

Das XBIOS sorgt daher nicht nur für die “Umlenkung” von Kanal 1 auf die passenden 
Routinen, sondern auch für die Umschaltung auf eine entsprechende “Rsconf()”-Routine. 
Auch für die Anpassung der “Iorec()”-Funktion wird gesorgt. 

“Bconmap” verfügt dazu über eine BCONMAP-Struktur, die entsprechende Funktionszeiger 
für die einzelnen Geräte enthält: 

typedef struct 
{ 

WORD (*Bconstat) (); /* Funktionszeiger */ 

LONG (*Bconin) OB¬ 
LONG (*Bcostat) {); 

void (*Bconout) (); 

ULONG (*Rsconf) (); 

IOREC *iorec; 

} MAPTAB; 


/* Zeiger auf IOREC-Struktur */ 
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typedef struct 
{ 

MAPTAB *maptäb; /* Zeiger auf Funktionstabelle */ 

WORD maptabsize; /* Anzahl der Einträge */ 

} BCONMAP; 

“maptabsize” gibt an, wie viele erweiterte Kanäle bereits installiert sind. Wenn man 5 addiert, 
erhält man die größte erlaubte Nummer für die BlOS-Zeichenfunktionen und natürlich für 
“BconmapO”. 

“maptab” zeigt auf ein Feld von “maptabsize” MAPTAB-Strukturen, Jede dieser Strukturen 
enthält Zeiger auf die entsprechenden BlOS-Zeichenfunktionen, eine “Rsconf()”-Funktion 
und den IOREC des betreffenden Geräts. 

Die neue Vielfalt bei den seriellen Schnittstellen hat natürlich einige wichtige Konsequenzen: 

- Viele der mit “Rsconf()” möglichen Einstellungen sind eng mit der Hardware des MFP- 
Bausteins verbunden. Daher muß man sich damit abfinden, daß viele Einstellungen nicht 
mehr unbedingt bei jeder Schnittstelle möglich sind. 

- Direkte Folge: Einstellungen der seriellen Hardware sollten im allgemeinen spezialisier¬ 
ten Konfigurationsprogrammen wie dem Kontrollfeld Vorbehalten bleiben und aus den 
eigentlichen Anwendungsprogrammen entfernt werden. 


Blockorientierte Funktionen 

Einleitung 

Als blockorientiert bezeichnet man gemeinhin Geräte, die Daten ausschließlich in größeren 
Blöcken (meist Sektoren genannt) übertragen können. BIOS kann 32 derartige Geräte 
verwalten. Dazu stehen folgende Funktionen zu Verfügung: 

Drvmap(): Liste der verfügbaren Geräte abfragen 

Getbpb(): Informationen über das Gerät abfragen 

Mediach(): Medienwechselstatus erfragen 


Rwabs(): 


Sektoren lesen oder schreiben 
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DrvmapQ: Wie viele Geräte gibt es? 

Zur Buchführung über die vorhandenen Geräte benutzt BIOS die Systemvariable “„drvbits”. 
Jedes Bit in “_drvbits” entspricht einem verfügbaren Gerät. Wer eigene BIOS-Treiber 
installiert, muß also das passende Bit in “_drvbits” setzen, um das Gerät anzumelden. Wer den 
Wert nur abfragen will, sollte statt dessen die BIOS-Funktion “DrvmapO” zu Rate ziehen 
(wenn man die Wahl hat, sollte man immer eine Betriebssystemfunktion der Benutzung einer 
Systemvariablen vorziehen). 

Ein gesetztes Bit bedeutet natürlich noch längst nicht, daß auch Daten gelesen oder 
geschrieben werden können. Die Drive-Bits geben nur darüber Auskunft, für welche 
Gerätenummem ein Treiber installiert ist. Man stelle sich vor, es wäre anders: dann müßte Bit 
0 in dem Moment gelöscht werden, in dem die Diskette aus Laufwerk A: entfernt wird (das 
gleiche gilt natürlich auch für jedes andere wechselbare Medium, zum Beispiel für eine 
Wechselplatte). 

Und noch ein wichtiger Hinweis: BIOS-Geräte und GEMDOS-Laufwerke müssen nicht das 
gleiche sein. Das erkennt man schon daran, daß BIOS zur Zeit doppelt so viele Geräte wie 
GEMDOS erlaubt. Bei Benutzung von “Meta-DOS” kann es außerdem Vorkommen, daß 
GEMDOS Geräte nicht über BIOS, sondern über einen von “Meta-DOS” installierten Treiber 
ansteuert. Die Liste der für GEMDOS verfügbaren Geräte sollte man daher besser mit 
“Dsetdrv()” abfragen! 


Getbpb(): Informationen über ein Gerät ermitteln 

“GetbpbO” liefert eine Geräteinfonnationsstruktur folgender Form: 


typedef struct 
{ 

WORD recsiz; 

/* 

WORD 

clsiz; 

/* 

WORD 

clsizb; 

/* 

WORD 

rdlen; 

/* 

WORD 

fsiz; 

/* 

WORD 

fatrec; 

/* 

WORD 

datrec; 

/* 

WORD 

numcl ; 

/* 

WORD 

bflags; 

/* 


Bytes pro Sektor */ 

Sektoren pro Cluster (Einheit) */ 

Bytes pro Cluster */ 

Länge d. Wurzelverzeichnisses in Sektoren*/ 
Länge des File Allocation Table (FAT) */ 
Startsektor der zweiten FAT */ 

Sektornummer des ersten freien Clusters */ 
Gesamtzahl der Cluster auf dem Medium */ 
Bitvektor, zur Zeit nur Bit 0 belegt: 

0 (12-Bit-FAT), 1 (16-Bit-FAT) */ 


} BPB; 
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Eigentlich würde man erwarten, daß sich BIOS an dieser Stelle nur für die Anzahl der Sektoren 
und ihre Größe in Bytes interessiert. Wie man aber sieht, sind schon alle für das GEMDOS- 
Dateisystem interessanten Informationen eingetragen. Wie paßt das zur sonst so einleuchten¬ 
den Aufteilung in “höhere” und “niedrigere” Betriebssystemschichten? 

Die hier zurückgelieferten Informationen werden bei praktisch allen Medien aus dem 
Bootsektor (Sektor 0) ermittelt, der eben auch schon Informationen über die logischen 
Strukturen enthält. GEMDOS selbst braucht sich damit nicht in die Niederungen von 
Bootsektoren und ähnlichem Kram herabzubewegen. Weitere Informationen zur BPB- 
Struktur finden Sie konsequenterweise in der Einführung zum GEMDOS-Dateisystem. 

Bedeutet dies, daß BIOS nur Geräte mit GEMDOS-Dateisystem bedienen kann? Keinesfalls! 
Hauptsache ist nur, daß im BPB alle Felder mit sinnvollen Werten besetzt sind. Die 
Gesamtzahl der Sektoren kann man daraus dann selbst berechnen und fortan per “Rwabs()” 
auf das Gerät zugreifen: 

/* Anzahl der verfügbaren Sektoren eines BIOS-Geräts feststellen. 
Return-Wert ist entweder die Anzahl oder im Fehlerfall 0 */ 

LONG SecCount (WORD device) 

{ 

BPB *B = Getbpb (device); 
if (!B) /* Fehler? */ 

return OL; 

eise 

return B->datrec + (LONG)B~>numcl * B->clsiz; 

} 


MediachO: Medien Wechselstatus erfragen 

Das BIOS kommt auch mit wechselbaren Medien zurecht. Dazu gibt es einerseits definierte 
Fehlermeldungen, die ein Treiber zurückliefem darf. Andererseits gibt es auch die Funktion 
“MediachO”, mit der man sich explizit über den Status des Mediums informieren kann. 

Da aus technischen Gründen nicht bei allen Gerätetypen eine sichere Auskunft möglich ist, 
gibt es auch für “kann sein” einen definierten Return-Wert. 

Vorsicht mit defekten Diskettenlaufwerken oder nicht einwandfrei funktionierenden 
Wechselplattentreibern: GEMDOS ist absolut darauf angewiesen, daß die Medienwechsel¬ 
erkennung funktioniert. Anderenfalls ist es sehr wahrscheinlich, daß früher oder später 
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Verwaltungsinformationen (FAT, Verzeichnisse) auf das falsche Medium geschrieben 
werden! 


Rwabs(): Sektoren lesen und schreiben 

Über diese Funktion werden alle Lese- und Schreibzugriffe abgewickelt. Für zum AHDI 3.0 
kompatible Festplattentreiber wurde die Funktionsdefinition in Hinsicht auf Retries (Wieder¬ 
holungen im Fehlerfall) und auf den direkten Plattenzugriff erweitert. 


Installation eigener Treiber 

Die Installation eigener BIOS-Treiber ist sehr einfach, da es für die drei letztgenannten 
Funktionen Systemvektoren gibt. Ein neuer Treiber muß also nur einen entsprechenden 
Eintrag in der Systemvariable “_drvbits” vornehmen und sich in die Vektoren “hdv_rw”, 
“hdv_mediach” und “hdv_bpb” einklinken. Da man sich die Vektoren ja unter Umständen mit 
anderen Treibern teilt, sollten dabei folgende Regeln beachtet werden: 

1. Es sollte das XBRA-Verfahren für vektorverbiegende Programme benutzt werden, 
damit andere Treiber korrekt weiterfunktionieren (und sich gegebenenfalls wieder ent¬ 
fernen können). 

2. Alle Funktionen erhalten die BIOS-Laufwerksnummer als Parameter, und jeder Treiber 
sollte höllisch genau darauf aufpassen, daß er sich nicht im falschen Moment angespro¬ 
chen fühlt. 


Treiber für Diskettenlaufwerke 

Einleitung 

Nach Systemstart kennt das BIOS zunächst nur Funktionen für die Diskettenlaufwerke, 
Während des Bootvorgangs wird versucht, beide Laufwerke anzusprechen. Das Ergebnis - 
die Anzahl der angeschlossenen Laufwerke - kann man in der Systemvariable “_nflops” 
finden (intern wird dazu über “hdvjnit” und “hdv_boot” gesprungen). Wenn Laufwerke 
gefunden wurden, trägt BIOS die Drive-Bits für Gerät 0 und Gerät 1 ein - ungeachtet der 
tatsächlichen Zahl von Diskettenlaufwerken. Ist nur ein Laufwerk angeschlossen, dann wird 
das zweite Gerät per Software “emuliert” (wer kennt die Meldung “Bitte Diskette B: in 
Laufwerk A einlegen” nicht?). 
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Für seine Lese- und Schreibzugriffe bedient sich der BIOS-Diskettentreiber der XBIOS- 
Funktionen “Floprd()”, “FlopwrO” und gegebenenfalls “FlopverO” (und zwar dann, wenn die 
Systemvariable “_fverify” es so will). 


Der Bootsektor 

Wie man weiß, gibt es eine große Zahl von möglichen Diskettenformaten. Grund sind nicht 
nur die unterschiedlichen technischen Voraussetzungen (einseitig oder doppelseitig, 40 oder 
80 Spuren, 5 1/4 oder 3 1/2 Zoll, normale oder hohe Schreibdichte), sondern auch die 
vielfältigen Versuche der ST-Besitzer, ihren Diskettenlaufwerken auch noch das letzte Byte 
zu entlocken (was vor dem Siegeszug der Festplatten auch wirlich ein wichtiges Thema war). 

Zum Glückerweistsich das BIOS in dieser Hinsicht als sehrflexibel.NachjedemMedienwechsel 
inspiziert es den Bootsektor der eingelegten Diskette. Dieser sollte folgende Daten enthalten: 


Offset 

Name 

Belegung 

$00 

BRA.S 

CPU-Sprungbefehl zur Bootroutine 

$02 

FILLER 

6 Füllbytes 

$08 

SERIAL 

3 Bytes Seriennummer 

$0B 

BPS 

Bytes pro Sektor 

$0D 

SPC 

Sektoren pro Cluster 

$0E 

RES 

Reservierte Sektoren am Anfang des Mediums 

$10 

NFATS 

Anzahl der File Allocations Tables 

$11 

NDIRS 

Anzahl der Einträge im Wurzelverzeichnis 

$13 

NSECTS 

Gesamtzahl der Sektoren 

$15 

MEDIA 

“Media”-Byte 

$16 

SPF 

FAT-Größe in Sektoren 

$18 

SPT 

Track-Größe in Sektoren 

$1A 

NSIDES 

Seiten pro Medium 

$1C 

NHID 

Versteckte Sektoren 


Da Sinn und Zweck des GEMDOS-Dateisystems ist, MS-DOS-Disketten lesen und beschrei¬ 
ben zu können, liegen alle 16 Bit großen Werte im Intel-Format (also High- und Low-Byte 
vertauscht!) vor! 


Die Bedeutung der Felder im einzelnen: 

BRA.S Dieses Feld ist nur bei auto-bootenden Disketten interessant und enthält dann 
einen Branch-Befehl zur eigentlichen Bootroutine. 
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FILLER Sechs Bytes, die beliebig vergeben und für eigene Zwecke benutzt werden dür¬ 

fen. 

SERIAL Eine 24 Bit große Seriennummer. Diese Seriennummer wird bei einem “unsi¬ 
cheren” Medienwechselstatus begutachtet und sollte nach Möglichkeit für jede 
benutzte Diskette verschieden sein (siehe auch “ProtobtO”). 

BPS Sektorgröße in Bytes. 

SPC Sektoren pro GEMDOS -Cluster. 

RES Anzahl der reservierten Sektoren (meist 1, weil der Bootsektor nur einen Sektor 

“verbraucht”). 

NFATS Anzahl der File Allocation Tables (unter GEMDOS immer 2). 

NDIRS Anzahl der Einträge im Wurzelverzeichnis (im Gegensatz zu Unterverzeichnis¬ 

sen ist die Größe bei einem Wurzelverzeichnis ein fester Wert). 

NSECTS Gesamtzahl der Sektoren (inklusive der reservierten, also des Bootsektors). 

MEDIA “Media”-Byte. Dieses Byte wird vom BIOS nicht ausgewertet, da sich alle 
interessanten Informationen besser auf andere Weise ermitteln lassen. Anders 
unter MS-DOS (dazu gleich mehr). 

SPF FAT-Größe in Sektoren. 

SPT Anzahl der Sektoren pro Spur. 

NSIDES Anzahl der Seiten (bei Disketten normalerweise 1 oder 2, wer hätte etwas 
anderes erwartet?). 

NHDD Wird vom BIOS ignoriert. 

Das XBIOS bietet übrigens zum Erzeugen “frischer” Bootsektoren die Funktion “ProtobtO” 

an. 

Bootsektoren bei MS-DOS-Disketten 

Leider ist es mit der MS-DOS-Kompatibilität nicht ganz so einfach, wie man es sich wünschen 

würde. 
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Das hat verschiedene Ursachen. Zuerst einmal hat ein MS-DOS-Bootsektor eben nur fast das 
gleiche Format: 


Offset 

Belegung 

$00 

CPU-Sprungbefehl zur Bootroutine 

$03 

Acht Zeichen langer Diskettenname 


Der Sprungbefehl ist also ein Byte länger und natürlich in der Maschinensprache der Intel- 
Chips gehalten. Leider erwarten die meisten PC-Kompatiblen an dieser Stelle tatsächlich eine 
Intel-Befehlssequenz und weigern sich ansonsten beharrlich, die Diskette zu verarbeiten. 
Daher sollte man die ersten drei Bytes stets mit den Zahlen $E9 $00 $4E füllen. Folge: MS- 
DOS-kompatible Disketten sind auf dem Atari nicht bootbar. 

Nächstes Problem: da, wo das Atari-BIOS eine zufällige Seriennummer erwartet, steht bei 
MS-DOS-Disketten ein “Diskettenname” (etwa: “MS-DOS 3.2”). Die Folge: wenn man 
mehrere gleich formatierte Disketten abwechselnd benutzt, funktioniert die Medienwechsel- 
erkennung nicht so, wie man es sich wünschen würde. 

Kommen wir zum “Media”-Byte. Auch dieses Byte entstammt den Ursprüngen von MS-DOS 
und dient dort dazu, die verschiedenen Diskettentypen auseinanderzuhalten. Daß dabei längst 
nicht die gleiche Vielfalt wie über die anderen Felder des Bootsektors zu ereichen ist, dürfte 
klar sein. Dennoch bestehen viele MS-DOS-Versionen darauf, daß dieses Feld einen “vernünf¬ 
tigen” Wert hat (diese Liste erhebt weder Anspruch auf Vollständigkeit noch auf absolute 
Korrektheit): 


Wert Bedeutung 


$F8 

$F9 

$FC 

$FD 

$FE 

$FF 


Festplatte oder einseitige Diskette mit 80 Spuren zu 9 Sektoren (360K) 

Doppelseitige Diskette, 80 Spuren zu 9 oder mehr Sektoren (High-Density) 

Einseitige Diskette, 40 Spuren zu 9 Sektoren 

Doppelseitige Diskette, 40 Spuren zu 9 Sektoren 

Einseitige Diskette, 40 Spuren zu 8 Sektoren 

Doppelseitige Diskette, 40 Spuren zu 8 Sektoren 


Wer meint, nun wäre MS-DOS zufrieden, der irrt. Zusätzlich muß man noch die ersten beiden 
(unbenutzten) Einträge beider FATs mit einer Kopie der Media-Bytes und folgenden $FFs 
füllen (wozu auch immer das gut sein soll). Fest steht, daß das Desktop ab GEM 1.4 auf 


den Intel-Sprungbefehl am Anfang des Bootsektors und 
die Kopien des Media-Bytes am Beginn der FATs 
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achtet und solche Disketten erfahrungsgemäß auf PCs erfolgreich gelesen und beschrieben 
werden können. 

Schlußbemerkung zu diesem Thema: das BIOS des Atari hat normalerweise gar keine 
Probleme, auf PCs formatierte Disketten zu “verdauen”. Im Zweifelsfall ist also die sicherste 
Lösung, die Diskette dort zu formatieren, wo sie später gelesen werden soll. 


Bootbare Disketten 

Wozu gibt es eigentlich bootbare Disketten? Wäre es nicht viel einfacher, das zu startende 
Programm in den AUTO-Ordner zu kopieren? 

Die ersten ausgelieferten STs verfügten nur über ein 64 KByte großes Betriebssystem, das 
gerade einmal zum Laden des TOS von Diskette reichte. Diese ROMs hatten die Versionsnum- 
mer 0.00 und wurden von Atari allen Ernstes “Das Boot” genannt. Neben einer netten Grafik¬ 
demo enthielten sie die BIOS-Funktionen “RwabsO” und “GetbpbO” und die XBIOS-Funk- 
tionen “SsbrkO” und “FloprdO” -gerade eben genug, um Sektoren von einer Diskette zu lesen. 

Ohne GEMDOS-Funktionen kann man aber nicht auf Dateien zugreifen, und so muß die dazu 
nötige Software “gebootet” werden. 

Andere Anwendungen für bootbare Disketten: 

- Fremde Betriebssysteme wie Minix, die, sind sie einmal geladen, die gesamte System¬ 
verwaltung sowieso selbst übernehmen. 

- Videospiele, die ebensowenig Betriebssystemroutinen brauchen, aber möglichst 
unkompliziert geladen werden sollen. 

- Kleine Hilfsprogramme, die möglichst früh während der Systeminitialisierung gestartet 
werden sollen (bei Anwendern ohne Festplatte sehr beliebt). 

Das BIOS wertet den Bootsektor während der Systeminitialisierung aus (und springt dazu 
durch den Vektor “hdv_boot”). Dazu wird er in einen Puffer geladen und dort eine Prüfsumme 
über die 256 16-Bit-Werte berechnet. Ist das Ergebnis $1234, dann wird zum ersten Byte im 
Sektor gesprungen. Die Adresse des Puffers ist nicht dokumentiert, und so muß die im 
Bootsektor enthaltene Routine positionsunabhängig programmiert sein. Für die Routine im 
Bootsektor gibt es nun zwei Möglichkeiten, wie sie fortfahren kann. Einerseits darf sie die 
Kontrolle per “rts” an das BIOS zurückgeben, das dann mit dem normalen Startvorgang 
fortfährt (dann darf sie allerdings keine Register verändern). Andererseits kann sie die Kon- 
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trolle auch ganz selbst übernehmen und dann beispielsweise ein völlig anderes Betriebssystem 
(oder ein Spiel) laden. 

Ausführbare Bootsektoren sind übrigens nicht nur für Utilities und Betriebssysteme, sondern 
auch für Virenprogramme interessant. 

Daher sollte man niemals mit “fremden” Disketten im Laufwerk booten! 


Diskettenwechsel 

Eine Beschreibung des Floppytreibers im BIOS wäre natürlich unvollständig, wenn das 
Thema “Diskettenwechsel” fehlen würde. Im Gegensatz zu anderen Systemen (wie dem 
Macintosh) bietet die Hardware beim Atari keine direkte Methode, Diskettenwechsel zu 
registrieren. Das BIOS überwacht statt dessen im Vertical Blank das Schreibschutzsignal, das 
bei einem Diskettenwechsel kurz unterbrochen wird. Das hat mehrere Folgen: 

- Bei schreibgeschützten Disketten meldet das BIOS immer “vielleicht gewechselt”. Ab 
TOS 1.04 wurde wenigstens eine Plausibilitätsprüfung eingeführt, die die .Anzahl der 
gemeldeten Wechsel reduziert (dazu merkt sich das BIOS, wann der letzte Wechsel 
erfolgt ist, und geht dann davon aus, daß innerhalb eines bestimmten Zeitraums ganz 
bestimmt nicht noch ein Diskettenwechsel möglich ist). 

- Für unsichere Fälle benötigt das BIOS die Seriennummer im Bootsektor. Wer mehrere, 
gleichartig formatierte Disketten mit gleicher Seriennummer abwechselnd benutzt, muß 
also mit Fehlem rechnen. 

- Weitere Probleme sind vorprogrammiert, wenn man eine Diskette abwechselnd in zwei 
Rechnern benutzt. Szenario: Diskette wird aus Rechner A entnommen. Auf Rechner B 
wird eine neue Datei auf die Diskette geschrieben. 

Anschließend wird die Diskette wieder in das Laufwerk von Rechner A eingelegt. Das 
BIOS hat die Unterbrechung der Schreibschutz-Leitung entdeckt und meldet einen 
möglichen Medienwechsel. Daher wird die Seriennummer im Bootsektor überprüft - 
und für gleich befunden! Wenn jetzt Rechner A einen Schreibzugriff macht, werden mit 
einiger Wahrscheinlichkeit die von Rechner B veränderten Verwaltungsinformationen 
wieder mit den alten, vom GEMDOS gepufferten Werten Uberschrieben. 

Abhilfe: das BIOS zwingen, die Diskette als gewechselt anzusehen (wie zum Beispiel 
durch Drücken der <Esc>-Taste im Desktop). Die dazu notwendige Funktion ist in der 
Einführung zum GEMDOS beschrieben. 
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Formatieren von Disketten 

Folgende Schritte sind notwendig, um eine “frische” Diskette zu erzeugen: 

1. Alle Spuren beider Seiten mit “FlopfmtO” formatieren. Wenn in den ersten Sektoren 
Fehler auftreten, dann ist die Diskette unbrauchbar (dieser Platz wird für die 
Verwaltungsinformationen benötigt). 

Andere Defektsteilen können theoretisch später in der FAT eingetragen werden. Bei den 
heutigen Diskettenpreisen lohnt sich das aber wegen der zu erwartenden verminderten 
Datensicherheit wohl nicht. 

2. Der von Bootsektor, FATs und Wurzelverzeichnis belegte Platz muß gelöscht werden. 
Normalerweise sollte es reichen, dazu die ersten zwei Spuren mit “Flopwr()” zu löschen 
(also mit Nullen zu beschreiben). 

3. Mit der BIOS-Funktion “ProtobtO” wird ein geeigneter Bootsektor erzeugt. Für MS- 
DOS-kompatible Disketten müssen eventuell noch der Anfang des Bootsektors (im 
Speicher) und die Anfänge der beiden FATs (auf der Diskette) modifiziert werden. 

4. Der Bootsektor wird mittels “FlopwrO” in Sektor 1 auf Spur 0, Seite 9 geschrieben. 


Softwareunterstützung für “High-Density” 

Für die Erkennung “High-Density”-fähiger Floppyhardware und entsprechender 
Betriebssystemroutinen kann der “ FDC”-Cookic benutzt werden. Ihm kann man entnehmen, 
was die höchste vom System unterstützte Schreibdichte ist. 

Zur Zeit sind (zusätzlich zur Standardhardware) nur Werte für “High-Density” (1) und “Extra- 
High-Density” (2) dokumentiert. 

Unterschiede ergeben sich dadurch eigentlich nur für die XBIOS-Funktionen “FIoprd()’\ 
“FlopwrO”, “FlopfmtO”, “FlopverO” und “ProtobtO”. Indirekt sind damit natürlich auch die 
BIOS-Routinen “Rwabs()”, “GetbpbO” und “Mediach()” betroffen. 

Für die vier “Fiop...()”-Aufrufe ergeben sich nur in Hinsicht auf die maximal erlaubte 
Sektorzahl Unterschiede (bei höheren Sektorzahlen wird entsprechend das richtige Format 
gewählt). “ProtobtO” wird um neue Opcodes für Bootsektoren entsprechender Diskettentypen 
erweitert. 
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Treiber für Festplatten 


Einleitung 

Prinzipiell könnte das BIOS Festplatten wie ganz normale Diskettenlaufwerke behandeln. 
Aus verschiedenen Gründen geht es allerdings anders vor: 

- Zur Markteinführung des ST war der Platz in den 192 KByte großen ROMs ausgespro¬ 
chen wertvoll. Da es 1985 sowieso noch keine Festplatten für den ST zu kaufen gab, hat 
man dem BIOS gerade eben das Nötigste verpaßt, um den Treiber wenigstens von einer 
Platte booten zu können (es dauerte allerdings bis 1987, bis die Atari-Festplattensoftware 
dies auch ausnutzen konnte). 

- Auf Festplatten paßt erheblich mehr als auf eine Diskette. Schon die ersten ST- 
Festplatten mit 20 MB Speicherkapazität überschritten die damals für GEMDOS 
maximale Mediengröße. Daß die Plattengrößen weiterwachsen würden, war leicht 
vorauszusehen. 

Daher enthalten TOS-Versionen vor 2.00 keinen eigenen Festplattentreiber, sondern nur eine 
Routine zum Lesen und Ausführen des Rootsektors (Sektor 0) der Platte. TOS-Versionen ab 
2.00 können über die XBIOS-Funktionen “DMAread()” und “DMAwriteO” auf Festplatten 
zugreifen, die fertige Einbindung als Treiber gibt es aber auch hier nicht. Da diese Routinen 
allerdings nicht geschwindigkeitsoptimiert sind, greifen die allermeisten Festplattentreiber 
(auch die von Atari) direkt auf die Hardware zu. 

Die GEMDOS-spezifischen Kapazitätsgrenzen werden folgendermaßen umgangen: der 
verfügbare Speicherplatz des physikalischen Mediums wird auf mehrere logische Laufwerke 
verteilt. Diese logischen Laufwerke werden gemeinhin Partitionen genannt und haben eine 
für GEMDOS akzeptable Maximalgröße. Einige Vorteile dieses Partitionierung genannten 
Verfahrens: 

- Kleinere Medien bedeuten für das Dateisystem weniger Arbeit und mehr Geschwindig¬ 
keit (wegen des geringeren Verwaltungsaufwands). 

- Mehr Übersicht - speziell in Verbindung mit Programmen, die die Stärken eines 
hierarchischen Dateisystems schlecht ausnutzen (gemeint ist das alte GEM-Desktop, das 
nur Laufwerks-, aber keine Ordnersymbole auf dem Desktophintergrund ablegen kann). 

- Nicht jede der Partionen muß auch tatsächlich ein GEMDOS-Dateisystem enthalten. 
Damit ist es möglich, auf einer Festplatte mit verschiedenen Betriebssystemen (Minix, 
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Macintosh-Emulation) zu arbeiten. Und mit Meta-DOS wäre es sogar denkbar, fremde 
Dateisysteme für GEMDOS zugänglich zu machen. 

- Prinzipbedingt führen “Unfälle” im Dateisystem meist nur zum Dateiverlust auf einer 
Partition. 

- Viele Festplattentreiber bieten die Möglichkeit, einzelne Partitionen gezielt gegen 
Schreibzugriffe zu schützen, was beim Testen neuer Software gegen unliebsame Über¬ 
raschungen schützen kann. 

Die Einteilung in mehrere Partitionen ist übrigens keine Erfindung von Atari. Auch unter MS- 
DOS und unter Unix (wenn auch dort aus anderen Gründen) gibt es Partitionen. 


Bootvorgang 

Das BIOS untersucht nacheinander die Rootsektoren der angeschlossenen Festplatten, und 
zwar beginnend mit der niedrigsten Gerätenummer (0). Beim TT werden erst die acht 
möglichen SCSI-Geräte und dann erst die ACSI-Geräte begutachtet. 

Je nach TOS-Version werden dabei unterschiedliche Strategien benutzt: 

- Bis einschließlich TOS 1.02 wird pro Gerät nur ein Leseversuch gestartet. 

- In TOS 1.04 wird bei Fehlern ein zweiter Versuch gemacht - vorausgesetzt der Fehler 
war kein Time-Out (zu deutsch: Gerät nicht vorhanden). 

- TOS 1.06 und TOS 1.62 benutzen beim Kaltstart großzügige Warteschleifen, so daß mit 
vielen Platten das gleichzeitige Einschalten von Rechner und Platte möglich ist. 

- Ab TOS 2.05 (bzw. TOS 3.01) wird beim Kaltstart vor dem ersten Lesezugriff eine groß¬ 
zügige Pause von 90 Sekunden eingelegt. Damit soll den im Mega STE bzw. TT einge¬ 
bauten Platten Gelegenheit gegeben werden, sich zu initialisieren (wie sollte man bei 
diesen Geräten auch Platte und Rechner getrennt einschalten?). 

Kann ein Sektor gelesen werden, und hat die Prüfsumme (analog zum Booten von Disketten) 
den Wert $1234, dann wird zum ersten Byte des gelesenen Sektors gesprungen. Offizielle 
Unterlagen zu den Parametern dieser Routine gibt es leider nicht. Eine Analyse des vom AHDI 
(“Atari Hard Disk Interface”) 4.0 benutzten Rootsektors ergab folgende Registerbelegung: 

D7 Bits 5..7 enthalten die Nummer des ACSI-Geräts, das gerade getestet wird. 
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D4 Bits 0..2 enthalten die Nummer des SCSI-Geräts, das gerade getestet wird. 

D3 Falls D3 die Long-Konstante “DM Ar” enthält, gilt die Information aus D4 (und man darf 
die XBIOS-Funktion “DMAreadO” aufrufen), ansonsten die aus D7. 

Der im Rootsekfor enthaltene Programmcode kann nun den eigentlichen Treiber nachladen, 
die BlOS-Vektoren und “_drvbits” passend initialisieren und dann ins BIOS zurückkehren. 
Alte Versionen des AHDI (vor 3.0) haben die weitere Systeminitialisierung (Laden der 
Programme im AUTO-Ordner, Starten von GEM und Desktop) allerdings selbst übernom¬ 
men. 

Wer es noch immer nicht gemerkt hat: den Festplattentreiber in den AUTO-Ordner einer 
Festplatte zu kopieren ist weder sinnvoll noch klug! Um die Programme im AUTO-Ordner 
überhaupt laden zu können, muß sowieso schon ein Festplattentreiber initialisiert sein! 
Normalerweise übernimmt der Rootsektor die Aufgabe, die Treiberdatei (beim AHDI: 
“SHDRIVER.SYS”) im Wurzelverzeichnis der Bootpartition zu finden und zu laden. 


Format des Rootsektors 

Die Bezeichnung Bootsektor bezieht sich immer auf den ersten Sektor eines logischen 
Laufwerks. Der Rootsektor bezeichnet den physikalisch ersten Sektor des Mediums. Da bei 
einer Diskette kein Unterschied zwischen logischem und physikalischem Laufwerk gemacht 
wird, liegt der Bootsektor einer Diskette in Sektor 0. 

Anders bei Festplatten, die in mehrere logische Laufwerke unterteilt sind: jede Partition einer 
Festplatte hat einen Bootsektor (BlOS-Sektomummer 0), die gesamte Festplatte aber nur 
einen Rootsektor. 

Wie wir bereits gesehen haben, macht das BIOS keinerlei Annahmen darüber, was in einem 
Rootsektor steht: wenn die Prüfsumme $1234 ist, wird er ausgeführt, sonst nicht. Prinzipiell 
bleibt es damit den verschiedenen Festplattentreibem überlassen, ob und wie sie die 
Unterteilung auf verschiedene Partitionen vornehmen. 

Praktikabel wäre das allerdings nicht: 

Gelegentlich möchte man neue oder andere Treiber installieren. Dann wäre es mehr als 
unbequem, müßte man die gesamte Platte neu einrichten. 

- Alternative Betriebssysteme müssen direkt auf den Rootsektor zugreifen, um die für sie 
vorgesehenen Partitionen finden zu können. 
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- Wechselplattenbesitzer möchten ihr Medium auch auf Rechnern mit anderen Festplatten- 

treibem ansprechen können. 

Zum Glück hat Atari das vom eigenen Festplattentreiber unterstützte Format ausführlich 
dokumentiert, und so spricht alles dafür, dazu kompatibel zu bleiben: 


Offset 

Name 

Belegung 

$102 

hd_siz 

Gesamtzahl der 512-Byte-Sektoren als LONG-Wert 

$1C6 

pOJig 

Informationen über Partition 0 

$107 

pOJd 


$1CA 

pO_st 


$1CE 

pO_siz 


$1D2 

PlJlg 

Informationen über Partition 1 

$1D3 

pl_id 


$1D6 

pl_st 


$1DA 

pl_siz 


$1DE 

P2_flg 

Informationen über Partition 2 

$1DF 

p2_id 


$1E2 

p2_st 


$1E6 

p2_siz 


$1EA 

p3_flg 

Informationen über Partition 3 

SIEB 

p3_id 


$1EE 

p3.st 


$1F2 

p3 siz 


$1F6 

bsl_st 

Anfang der “Bad Sector List” (LONG-Wert) 

$1FA 

bsl_cnt 

Länge der “Bad Sector List” (LONG-Wert) 

$1FE 


Platzhalter zur Errechnung der Prüfsumme 


Atari unterscheidet zwischen Standardpartitionen und Erweitermigspartitionen (“extended 
partitions”). 

Standardpartitionen enthalten normalerweise ein “logisches” Laufwerk, während Erweiterungs¬ 
partitionen dazu dienen, mehr als die vier im Rootsektor vorgesehenen Partitionen auf der 
Festplatte unterzubringen. Von den vier Partitionseinträgen darf nur einer der letzten drei für 
eine Erweiterungspartition benutzt werden. Für jede Partition steht eine zwölf Bytes große 
Informationsstruktur zu Verfügung (das Fragezeichen steht jeweils für die Partitionsnummer): 

P?Jlg (ein Byte) 

Dieses Feld enthält Flags, die über einige Eigenschaften der Partition Auskunft geben: 
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Bit 0: Partition existiert (1) oder existiert nicht (0). Anhand dieses Bits kann man also 

feststellen, ob die betreffende Informationsstruktur überhaupt sinnvolle Daten 
enthält. 

Bit 1 ..6: reserviert (auf Null setzen) 

Bit 7: Partition ist bootbar (1) oder nicht bootbar (0). Der Atari-Festplattentreiber 

bootet von der ersten als bootbar gekennzeichneten Partition. 

p?_id (drei Bytes) 

Hier müssen drei Zeichen stehen, die den Typ der betreffenden Partition festlegen 
(Partitionskennung): 

“GEM”; Standard-GEMDOS-Partition (kleiner als 16 Megabyte) 

“BGM”: Große GEMDOS-Partition (“big GEMDOS partition”) 

“XGM”: Erweiterungspartition 

Andere Einträge werden von zum AHDI 3.0 kompatiblen Treibern ignoriert und können zur 
Kennzeichnung von Partitionen für andere Betriebssysteme benutzt werden. 

p?_st (LONG) 

Nummer des ersten Sektors der Partition, gerechnet ab Sektor 0. 
p?_siz (LONG) 

Größe der Partition in 512-Byte-Sektoren (die AHDI-Spezifikation sieht also Festplatten mit 
größeren Sektoren nicht vor). 


Partitionstypen 

Eine Standard-GEMDOS-Partition (Partitionskennung “GEM”) enthält als ersten Sektor 
einen Bootsektor, wie man ihn schon von Disketten her kennt. 

Da eine Festplattenpartition und eine Diskette aber eben doch nicht ganz vergleichbar sind, 
sind einige Anmerkungen zu den einzelnen Feldern notwendig: 

BRA.S Wie schon erwähnt, ist der Programmcode zum Booten bei Festplatten im 
Rootsektor abgelegt. Normalerweise ist also der Bootsektor einer Partition für 
andere Zwecke frei. Viele Festplattentreiber nutzen den freien Platz, um hier 
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den restlichen zum Nachladen der Treiberdatei notwendigen Programmcode 
abzulegen. 

BPS Sektorgröße in Bytes (bei Standardpartitionen immer 512 Bytes) 

SPT bei Festplatten unbenutzt 

NSIDES bei Festplatten unbenutzt 

Frage: Wie erkennt der Festplattentreiber, ob das Medium eine I2-Bit-FAT oder eine 16-Bit- 
FAT hat? Gar nicht! Auf dem Atari haben Festplattenpartitionen immer nur I6-Bit-FATs (mit 
zwölf Bits käme man auch nicht weit). Anders bei MS-DOS: dort sind sowohl 12-Bit-FATs 
als auch 32-Bit-FATs möglich. 

Da ältere GEMDOS-Versionen nur 32766 Cluster pro Laufwerk verwalten können und die 
Sektorgröße auf 512 Bytes beschränkt ist, können solche Standardpartitionen nie größer als 
16 MByte werden. 

Große GEMDOS-Partitionen (Partitionskennung “BGM”) wurden mit AHDI 3.0 eingeführt, 
um die eben genannte Größenbeschränkung zu umgehen. Die maximale Kapazität einer 
Partition berechnet sich als das Produkt von maximaler Clusterzahl, der Anzahl von Sektoren 
pro Cluster und der Größe der Sektoren. Für die ersten beiden Werte zeigt sich GEMDOS leider 
überhaupt nicht kompromißbereit, und so mußte Atari auf größere Sektoren ausweichen. 

Da man sich allerdings meistens nicht aussuchen kann, wie groß die Sektoren auf der Festplatte 
sein sollen (fast immer sind es 512 Bytes), täuscht der Festplattentreiber dem BIOS einfach 
die größeren Sektoren vor. Dazu faßt er einfach immer mehrere physikalische Sektoren zu 
einem logischen Sektor zusammen. 

Bei BGM-Partitionen ist der Bootsektor also wie folgt geändert: 

BPS Sektorgröße in Bytes (512, 1024, 2048,4096 oder 8192 Bytes) 

Bei “großen” Sektoren wird der “Rest” des Bootsektors (also alles bis auf die ersten 512 Bytes) 
mit Nullen aufgefüllt und hat weiter keine Bedeutung. 

Damit ist es allerdings noch nicht getan: auch GEMDOS muß darüber informiert werden, wie 
groß ein Sektor maximal werden kann - schließlich hat es dafür eigene Pufferlisten, die 
entsprechend modifiziert sein wollen (mehr dazu in der Einleitung zum GEMDOS unter 
“GEMDOS-Puffer”). Eigene Versuche ergaben übrigens, daß GEMDOS 8192 Bytes große 
Sektoren gar nicht gern mag (ausprobieren!). 
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Für die veränderte Partitionskennung (“BGM” anstelle von “GEM”) gibt es eigentlich keinen 
echten Bedarf: alle nötigen Informationen lassen sich schließlich aus dem Bootsektor heraus¬ 
lesen. Genauso verfährt auch AHDI 3.0: für ihn ist es völlig egal, ob die Partitionskennung 
“GEM” oder “BGM” ist. 

Doch was würde passieren, ließe man einen “alten” Treiber auf die Festplatte los? Richtig: 
er würde wahrscheinlich die angegebene Sektorgröße ignorieren und einen ungenießbaren 
Datensalat fabrizieren. 

Daher sollte man die Partitionskennungen wie folgt interpretieren: 

“GEM”: für alle Festplattentreiber nutzbar 

“BGM”: Festplattentreiber muß mit größeren logischen Sektoren zurechtkommen (also 

kompatibel zu AHDI 3.0 sein) 

Eine weitere Einschränkung älterer Festplattentreiber war, daß sie nur maximal vier Partitionen 
unterstützen konnten. Kombiniert mit der Größenbeschränkung der einzelnen Partitionen war 
damit schon bei etwa 64 MByte großen Festplatten Schluß. Das war auch 1987 schon eine 
Einschränkung. 

An dieser Stelle kommen die Emeiterungspartitionen ins Spiel. Bevor ich zur Struktur dieses 
Partitionstyps komme, kann ich mir eine Bemerkung nicht verkneifen: Selbst nach dem 
Schreiben eines AHDI-3-kompatiblen Festplattenpartitionierers (“SCSI-Tool”) verstehe ich 
noch immer nicht, warum das Format gerade so aussieht, wie es aussieht. 

Der Grundgedanke läuft darauf hinaus, daß alle zusätzlichen Partitionen in Form einer 
verketteten Liste organisiert werden. Damit erlaubt das Format prinzipiell beliebig viele 
Partitionen. 

Eine Erweiterungspartition ist eine Partition, die aus mehreren Teilpartitionen bestehen kann. 
Jede dieser Teilpartitionen besteht aus einem Hilfs-Rootsektor und einer Standardpartition 
(wie sie oben beschrieben ist). Das Format eines Hilfs-Rootsektors ähnelt stark dem eines 
normalen Rootsektors. Einschränkungen sind: 

- Die Felder “hd_siz”, “bsl_st” und “bsl_cnt” sind nicht benutzt. 

- Maximal zwei der Partitionsinformationsstrukturen dürfen benutzt sein (und müssen 
direkt aufeinander folgen). Die anderen beiden Einträge müssen mit Nullen gefüllt sein. 

Die erste der beiden benutzten Informationsstrukturen muß für eine Standardpartition stehen. 
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Dabei gelten für einige der Felder leicht modifizierte Bedeutungen: 

p?_flg: Nur Bit 0 ist benutzt (und muß gesetzt sein), bootbare Partitionen können nur 

im “echten” Rootsektor installiert werden. Alle weiteren Bits sind reserviert. 

p?_id: Hier darf nicht “XGM” stehen. 

p?_st: Startsektor der Partition relativ zu diesem Hilfs-Rootsektor. 

Der folgende Eintrag darf leer sein (dann ist das Ende der verketteten Liste erreicht). 
Anderenfalls muß er einen Verweis auf den nächsten Hilfs-Rootsektor enthalten. Die 
einzelnen Felder sehen dann so aus: 

p?_flg: Nur Bit 0 ist benutzt (und muß gesetzt sein). Alle weiteren Bits sind reserviert. 

p? id: Muß “XGM” enthalten. 

p?_st: Startsektor der nächsten Teilpartition relativ zum ersten Sektor der Erweite¬ 

rungspartition (!). 

p?_siz: Größe der nächsten Teilpartition (normalerweise Partitionsgröße plus ein Sek¬ 

tor für den Hilfs-Rootsektor). 

Tip\ Wer AHDI-3-kompatible Software schreiben will, sollte eine Weile mit dem Festplatten- 
partitionierer “HDX” experimentieren und sich die erzeugten Rootsektoren genau ansehen! 


Bad sector list 

Festplatten tendieren schon wegen ihrer Größe dazu, die eine oder andere defekte Stelle 
aufzuweisen. Das gilt sogar für fabrikneue Platten. 

Harddisks nach dem ST506-Standard werden von außen durch Angabe von physikalischen 
Positionen auf der Platte gesteuert - also Zylinder, Kopf, Spur etc. (ganz ähnlich wie bei einem 
Diskettenlaufwerk). Die Hersteller solcher Platten liefern in der Regel eine Liste der Defekt¬ 
stellen mit. In den Atari-Festplatten SH 204, SH 205, Megafile 20, Megafile 30 und Megafile 
60 ist das ST506-Laufwerk allerdings indirekt über ein spezielles Controllerboard angeschlos¬ 
sen, so daß man sich nicht um die Geometrie der Platte zu kümmern braucht und direkt mit 
fortlaufend numerierten Sektoren arbeiten kann. 

Der von Atari eingesetzte Controller erlaubt es prinzipiell, defekte Sektoren “auszumappen”. 
Das heißt, daß der Controller intern eine Liste der defekten Stellen kennt und bei der Nume¬ 
rierung der Sektomummem selbsttätig ausfiltert. 
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Damit könnte man die Verwaltung der defekten Stellen eigentlich auf die Hardware abwälzen. 
Ob dies auch tatsächlich funktioniert, wird wohl vorläufig ungeklärt bleiben, da die Atari- 
Festplattensoftware von dieser Möglichkeit sowieso keinen Gebrauch macht und mittlerweile 
SCSI-Platten nicht nur im Mega STE und im TT weite Verbreitung gefunden haben. 

SCSI-Platten haben es nämlich beim Defektmanagement sehr viel einfacher. Der Hersteller 
testet die Platte und sorgt auf Controller-Ebene für das Ausmappen der Sektoren. De facto 
erhält der Kunde also eine hundertprozentig fehlerfreie Platte. 

Auch wenn neue Defekte auftreten, steht der SCSI-Controller hilfreich zur Seite. Die neuen 
Fehlerstellen werden einfach in die Defektliste aufgenommen - und schon sind sie “ver¬ 
schwunden”. Manche Plattentypen haben sogar eigens dafür vorgesehene Reservesektoren 
und -spuren; einige gehen sogar so weit, das Aus- und Um-Mappen bei Bedarf im laufenden 
Betrieb vorzunehmen. 

Leider nutzt Ataris “HDX” diese Möglichkeit nicht aus, obwohl das bei den in der Megafile 
44 und den im Mega STE und TT integrierten Festplatten möglich wäre. Anders steht es bei 
Festplattentools, die von Fremdherstellem geliefert werden (zum Beispiel das schon oben 
erwähnte “SCSI-Tool” von Hard & Soft). 

“HDX” geht einen anderen Weg: in der “Bad Sector List” - einem speziell dafür vorgesehe¬ 
nem Bereich auf der Platte - werden getrennte Listen für “Hersteller”-Defekte und neu aufge¬ 
tretene Defekte geführt. Beim Umpartitionieren der Platten werden die defekten Sektoren 
dann auf Ebene der FAT (also auf Dateisystem-Ebene) unschädlich gemacht. 

Wer ein Festplatten-Utility schreiben will, das diese “Bad Sector List” unterstützt, sollte sich 
beim Atari-Entwickler-Support die “ AHDI Release Notes” besorgen. Wem es nur nur darauf 
ankommt, die Platte so zu partitionieren, daß sie mit “HDX” weiterbearbeitet werden kann: 
als Länge der “Bad Sector List” den Wert 1 eintragen, den betreffenden Sektor vollständig mit 
Nullen füllen, und in das vierte Byte den Wert $ A5 eintragen (eine leere “Bad sector list” wird 
von “HDX” nicht akzeptiert)! 


Andere Plattenformate 

Das hier angegebene AHDI-3-Format ist erst 1989 von Atari eingeführt worden. Vorher gab 
es weder Erweiterungspartitionen noch größere Sektoren. 


Daneben wurden auch noch weitere Felder im Rootsektor benutzt, um Informationen über die 
Plattengeometrie (Zylinder, Köpfe, Spuren) bereitzustellen. Diese Felder sind nicht offiziell 
dokumentiert und zu allem Überfluß ohnehin zu nichts zu gebrauchen: 
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- Durch die Fehlerkorrekturfähigkeiten moderner SCSI-Platten ist es sowieso nicht mehr 
möglich, von logischen Sektomummem auf spezielle Positionen auf dem Medium zu 
schließen, 

- Viele SCSI-Platten benutzen eine variable Zahl von Sektoren pro Spur, um die äußeren 
Spuren der Platte besser nutzen zu können, 

- Die beschriebenen Felder belegen wertvollen Platz im Rootsektor, der unter Umständen 
für Programmcode benötigt wird. 

Daher sollte man sich auf keinen Fall darauf verlassen, an diesen Stellen des Rootsektors 
sinnvolle Daten vorzufinden. 

Beim alten Atari-Format war die maximale Plattengröße auf 64 MByte festgelegt. Kein 
Wunder, daß viele Hersteller andere Formate ersonnen haben, um mehr Partitionen auf einer 
Platte unterbringen zu können. 

Das heute von Atari benutzte Format hat allerdings zwei wichtige Vorteile: 

- Es ist vollständig zum alten Format kompatibel - selbst dann, wenn man versehentlich 
einen alten Treiber startet. 

- Es werden keine neuen Einträge im Rootsektor “verbraucht”. 

Der Rootsektor von MS-DOS-Festplatten sieht deutlich anders aus. Dies könnte einem ziem¬ 
lich egal sein, gäbe es nicht Wechselplatten. AHDI enthält tatsächlich Code, der die Benut¬ 
zung von unter MS-DOS partitionierten Syquest-Wechselmedien erlaubt. 

Das allerdings mit folgenden Einschränkungen: 

- Dieses “Feature” ist nicht offiziell dokumentiert — meist ein Zeichen dafür, daß es noch 
ungelöste Probleme gibt. 

- Genau diese Probleme könnten damit zu tun haben, daß MS-DOS-Wechselplatten oft 
Cluster zu vier Sektoren verwenden - was GEMDOS laut Dokumentation gar nicht mag. 


Die PUNINFO-Struktur 

Zum AHDI 3.0 kompatible Festplattentreiber installieren eine Struktur, die viel Wissenswer¬ 
tes über den Treiber und die Platte enthält: 



BIOS und XBIOS 


33 


typedef struct 
{ 

WORD 
BYTE 
LONG 
LONG 
LONG 
UWORD 
DWORD 
LONG 

} PUN_INFO; 

Zunächst fällt auf, daß die Felder innerhalb der Struktur nur Platz für 16 Einträge haben 
(obwohl das BIOS maximal 32 Geräte unterstützt). Dadurch kann man AHDI-3-kompatibel 
nur maximal 16 Gerätenummem verwalten. 

“puns” gibt an, für wie viele Geräte sich der Festplattentreiber zuständig fühlt. In der “pun”- 
Tabelle befinden sich nähere Informationen zu den BIOS-Geräten 0 bis 15: 

Bit 0..2: Gerätenummer der Festplatte. 

Bit 3: Bei gesetztem Bit handelt es sich um ein Gerät an der SCSI- Schnittstelle (sonst: 

ACSI). Dieses Bit ist zwar noch nicht offiziell dokumentiert, kann aber wohl 
ohne Vorbehalt benutzt werden. 

Bit 4..6: Reserviert. 

Bit 7: Wenn dieses Bit gesetzt ist, dann wird das BIOS-Gerät nicht vom Plattentreiber 

verwaltet (gilt beispielsweise für die beiden Diskettenlaufwerke auf den 
Gerätenummem 0 und 1). 

“part„start” enthält für jede (unterstützte) Gerätenummer die Nummer des Startsektors auf der 
betreffenden Festplatte. “P„cookie” ist ein Magie-Wert, mit dem man sich vergewissern soll¬ 
te, ob man tatsächlich eine gültige PUNJNFO-Struktur vor sich hat. 

Gleiches gilt für “P_cookptr” (der auf das vorherige Strukturelement zeigen sollte) und die 
Versionsnummer in “P_version”. 

Näheres zu “P_max_sector” finden Sie in der GEMDOS-Einleitung (Thema: GEMDOS- 
Puffer). Einige Felder dieser Struktur sind erst dann ausgefüllt, wenn ein “Getbpb()”-Aufruf 
für das Laufwerk stattgefunden hat. 


puns; 
pun[16]; 
part_start[16], 
P_cookie; 
*P_cookptr; 
P_version; 
P_max_sector ; 
reserved[16] ; 


/* Anzahl der Geräte */ 

/* diverse Flags */ 

/* Partitionsanfänge */ 
muß "AHDI" sein */ 
zeigt auf vorheriges Element */ 
/* 0x0300 oder größer */ 

/* maximale Sektorgröße */ 


/* 

/* 
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Einen Zeiger auf diese Struktur erhält man über die Systemvariable “pun_ptr”: 

/* Zeiger auf PUN_INFO-Struktur ermitteln. 

Liefert entweder den Zeiger oder im Fehlerfall 0 zurück */ 

PUN_INFO *getpun (void) 

{ 

PUN_INFO *P; 

LONG oldstack; 

oldstack = Super (OL); 

P = *((PUNJENFO **)(0x516L)); 

Super ((void *) oldstack); 

if (P) /* überhaupt gesetzt? */ 

if (P->P_cookie == 0x41484449L) /* Cookie gesetzt? */ 
if (P->P_cookptr == &(P~>P_cookie)) 
if (P->P_version >= 0x300) 
return P; 

return 0L; 

} 


Unterstützung von Wechselplatten 

Wechselplatten machen den Festplattentreibem auf vielfältige Art und Weise das Leben 
schwerer: 

1. Die Medien können gewechselt werden. 

2. Nicht jedes Medium muß die gleiche Anzahl von Partitionen besitzen. 

3. Unter Umständen will man später ein Medium mit größeren Sektoren als vorher anmel¬ 
den. 

Problem 1 läßt sich relativ leichtlösen, da das BIOS sowieso schon den Begriff “Mediachange” 
kennt und die Erkennung eines SCSI-Medienwechsels vergleichsweise einfach ist. 

Problem 2 hat zwei Seiten. Einerseits kann es passieren, daß das neu eingelegte Medium 
wewgerPartitionenhatals das beim Booteneingelegte. Was passiert nun mit der freigewordenen 
Laufwerksnummer? 
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Nichts, genausowenig wie bei einem Diskettenlaufwerk ohne Diskette: “Getbpb()” liefert, 
ebenso wie “MediacbO” und “RwabsQ”, auf Anfrage eine Fehlermeldung (0). 

Der umgekehrte Fall ist schwieriger: was passiert, wenn das neu eingelegte Medium mehr 
Partitionen hat als das vorherige? Atari ist auf eine Verlegenheitslösung ausgewichen: man 
meldet dem Treiber bei der Installation, wie viele Laufwerkskennungen er bei einer Wechsel¬ 
platte freihalten soll (wer hat eine bessere Lösung?). Die zusätzlichen Laufwerkskennungen 
sind dann in den “_drvbits” angemeldet, können aber erst nach Einlegen eines passenden 
Mediums angesprochen werden (ähnlich wie bei nicht eingelegten Disketten). 

Dazu - und das ist weniger elegant - muß man an der Treiberdatei herumpatchen (das Format 
ist im Anhang beschrieben). Andere Festplattentools (wie zum Beispiel das mittlerweile viel¬ 
zitierte “SCSI-Tool”) machen es dem Anwender mittels Dialogbox und Mausbedienung 
einfacher. 

Bei Problem 3 ist es ähnlich: da GEMDOS die maximale Sektorgröße für seine Pufferlisten 
kennen muß, ist eine nachträgliche Änderung schwierig. Einfacher ist es, dem Treiber von 
vornherein die maximal nötige Sektorgröße mitzuteilen. Auch dieser Wert kann beim AHDI 
in derTreiberdatei eingetragen werden (und wie immer geht es bei “SCSI-Tool” komfortabler). 
Weitere Informationen zu diesem Thema bei der Erörterung der GEMDOS -Pufferlisten in der 
GEMDOS-Einführung. 


Welche Partition bekommt welche Gerätenummer? 

Oft ist es nicht ganz einfach zu verstehen, wann ein Treiber die Partitionen welcher Platte unter 
welchen Laufwerksnamen anbietet: AHDI ist relativ clever und sucht selbsttätig auch auf 
mehreren angeschlossenen Platten nach anzusteuemden Partitionen. 

Dazu sucht er, immer beginnend bei Gerätenummer 0, nach Festplatten (beim TT werden 
zuerst die SCSI- und dann die ACSI-Geräte untersucht). Die Suche bricht ab, wenn eine 
Gerätenummer nicht belegt ist. 

Das heißt: Festplatten müssen, immer mit 0 anfangend, aufsteigende Gerätenummem aufwei¬ 
sen, Lücken sind nicht erlaubt. Damit ist es möglich, daß der Treiber zwar korrekt von einer 
unter ACSI-Nummer 1 laufenden Platte gebootet wird, dann aber keine Partitionen findet 
(weil die Suche mit Gerät 0 startet und auf dieser Nummer keine Platte reagiert). 

Andere Festplattentreiber sind da flexibler. Oft sind nicht nur Lücken, sondern auch Ver¬ 
tauschungen in der Gerätereihenfolge erlaubt. Damit kann man beispielsweise Partitionen auf 
Gerät 1 niedrigere BIOS-Gerätenummem zuordnen als denen auf Gerät 0. 
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Meta-DOS 

“Meta-DOS” erweitert XBIOS um ein Treiberkonzept für blockorientierte Geräte. Dafür hat 
Atari die Funktionsnummem 48 bis 63 reserviert. 

Meta-DOS erlaubt die Installation von Treibern für 26 blockorientierte Geräte. Ihre Funktio¬ 
nen werden über neue XBIOS-Aufrufe (insbesondere zum Öffnen und Schließen der Geräte 
und zum Lesen und Schreiben von Blöcken) bereitgestellt. 

Die Kommunikation von GEMDOS wird durch spezielle logische Gerätetreiber hergestellt 
(mehr dazu in der Einführung zum GEMDOS). 

Meta-DOS ist eine Betriebssystemerweiterung, die sich noch in Entwicklung befindet. Zur 
Zeit sind folgende Treiber verfügbar: 

- ein physikalischer Treiber für die CD-ROM-Laufwerke CDAR 504/505 

- logische Treiber für die beiden in Verbindung mit CD-ROMs gebräuchlichen Formate 
(“High Sierra” und ISO). 

In der Funktionsreferenz finden Sie die Dokumentation zu “Metainit()”. Weitere Informatio¬ 
nen finden Sie in den Meta-DOS-Entwickierunterlagen. 


Speicherverwaltung 

Bei der Speicherverwaltung hat das BIOS wenig zu tun. Es hat lediglich die Aufgabe, beim 
Systemstart den vorhandenen Arbeitsspeicher zu finden und zu initialisieren. Über die 
Funktion “GetmpbO” wird GEMDOS die Möglichkeit gegeben, eine erste TPA (mehr dazu 
im GEMDOS-Kapitel) anzulegen. 


BIOS- und XBIOS-Bindings 

BIOS und XBIOS nehmen ihre Parameter auf dem Stack entgegen. Dabei wird das letzte 
Argument aus der Parameterliste als erstes auf den Stack gelegt. Schließlich wird mit Hilfe 
der Anweisung “TRAP #13” der BIOS-Trap-Dispatcher bzw. mit “TRAP #14" der XBIOS- 
Dispatcher aktiviert. 

Funktionsergebnisse liefern BIOS und XBIOS im Prozessorregister DO zurück. Nur die 
Register D3-D7 und A3-A7 werden gerettet. Alle anderen können durch den Aufruf verändert 
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werden! Das Verhalten für illegale Funktionsnummem ist bis auf einige wenige Ausnahmen 
(“BlitmodeO” und “BconmapO”) nicht definiert. 

BIOS und XBIOS sind bis zu einem gewissen Maß re-entrant.Damit sind auch Aufrufe aus 
Interrupts oder von innerhalb von BIOS oder XBIOS möglich. Dabei sind allerdings einige 
wichtige Einschränkungen zu beachten: 

DerTRAP-Dispatcher benutzt einen festen Speicherbereich, umRegisterinhalte, Statusregister 
und Rücksprungadressen zu retten. Dieser Bereich bietet laut Atari nur für maximal drei 
Rekursionsstufen Platz. Als Zeiger auf diesen Speicherbereich dient die Systemvariable 
“savptr”. 

Ein anderes Problem resultiert daraus, daß ein Interrupt just zu dem Zeitpunkt auftreten kann, 
in dem der Dispatcher Register speichert oder wiederherstellt. Eigentlich sollte der Dispatcher 
während dieses Vorgangs alle Interrupts sperren - doch tut er es leider nicht. 

Für BIOS- oder XBIOS-Aufrufe aus einem Interrupt heraus muß man also so Vorgehen: 

; BIOS- oder XBIOS-Aufrufe aus dem Interrupt 
; Frei nach: The Hitchhiker's Guide to the BIOS 

savptr = $4A2 ; Zeiger auf Registerpuffer 

amount =46 ; soviel Bytes werden verbraucht 

im_interrupt: 

sub.l tamount, savptr ; Platz schaffen 

; hier dürfen BIOS- bzw. XBIOS-Aufrufe erfolgen 

add.l ttamount, savptr ; ...und wieder freigeben 

; und raus aus dem Interrupt 
rte 

Wichtige Einschränkung: nur ein einziger Interrupt-Händler darf gleichzeitig so verfahren! 


Fehlermeldungen 

0: E_OK (“OK (no error)”) 

Funktion erfolgreich ausgeführt (kein Fehler aufgetreten). 
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-I: ERROR (“Error”) 

Es ist ein Fehler aufgetreten, der nicht genauer spezifiziert werden kann. 

-2: EDRVNR (“Drive not ready”) 

Angesprochenes Gerät ist nicht angeschlossen, nicht funktionsbereit oder reagiert nicht 
innerhalb der gesetzten Frist (Timeout). 

-3: EUNCMD (“Unknown command”) 

Dem angesprochenen Peripheriegerät ist das gegebene Kommando unbekannt. 

-4: E_CRC (“CRC error”) 

Beim Lesen eines Sektors ist ein Fehler aufgetreten (aufgetreten bei der CRC-Überprüfung). 
-5: EBADRQ (“Bad request”) 

Das Peripheriegerät kann das Kommando nicht ausführen. Befehlsparameter und Kontext 
prüfen! 

- 6 : E_SEEK (“Seek error”) 

Der angesprochene Track konnte vom Laufwerk nicht erreicht werden. 

-7: EMEDIA (“Unknown media”) 

Leseversuch gescheitert, da das Medium keinen korrekten Bootsektor besitzt. 

-8: ESECNF (“Sector not found”) 

Der betreffende Sektor wurde nicht gefunden. 

-9: EPAPER (“Out of paper”) 

Drucker nicht betriebsbereit. 

-10: EWRITF (“Write fault”) 

Fehler bei Schreiboperation aufgetreten. 
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-11: EREADF (“Read fault”) 

Fehler bei Leseoperation aufgetreten. 

-12: EGENRL (“General error”) 

Allgemeiner Fehler (Kommentar im “Hitchhiker’s guide to the BIOS”: “Reserved for future 
catastrophes”). 

-13: EWRPRO (“Write on write-protected media”) 

Es wurde versucht, auf ein schreibgeschütztes Medium zu schreiben. 

-14: E_CHNG (“Media change detected”) 

Seit der letzten Schreiboperation wurde das Medium gewechselt. 

-15: EUNDEV (“Unknown device”) 

Das angesprochene Gerät ist dem Betriebssystem unbekannt. 

-16: EBADSF (“Bad sectors on format”) 

Beim Formatiervorgang wurden defekte Sektoren entdeckt. 

-17: EOTHER (“Insert other disk request)” 

Eine andere Diskette muß eingelegt werden. Tritt nur auf, wenn Laufwerk B: angesprochen 
wird, ohne angeschlossen zu sein. In diesem Fall wird der Benutzer aufgefordert, “Diskette 
B:” in das erste Laufwerk einzulegen. 

-18: EINSERT (“Insert disk”) 

Meta-DOS-Fehler: Medium einlegen! 

-19: EDVNRSP (“Device not responding”) 

Meta-DOS-Fehler: Gerät antwortet nicht. 
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Der OS-Header 

Der OS-Header ist eine Struktur, die viele wichtige Informationen über die TOS-Version 
sowie einige Zeiger auf andere Systemadressen enthält. Je nach Betriebssystemversion liegt 
er am Anfang des ROMs oder auch im RAM. Seine Adresse kann über die Systemvariable 
“_sysbase” ermittelt werden. Und so sieht er aus: 

typedef struct _osheader 


UWORD 

os_entry; 

/* 

BRAnch-Instruktion zum RESET- 
Handler, Offset $00 */ 

UWORD 

os_version; 

/* 

TOS-Versionsnummer, Offset $02*/ 

void 

*reseth; 

/* 

Zeiger auf RESET-Handler, 

Offset $04 */ 

struct 

osheader 




*os_beg; 

/* 

Basisadresse Betriebssystem, 
Offset $08 */ 

void 

*os end; 

/* 

Erstes nicht vom OS benutztes 
Byte, Offset $0C */ 

LONG 

os rsvl; 

/* 

reserviert, Offset $10 */ 

GEM_MÖPB 

*os_magic; 

/* 

Zeiger auf "GEM memory usage 
Parameter block", Offset $14 */ 

LONG 

os_date; 

/* 

TOS-Herstellungsdatum im BCD- 
Format, etwa $02061986 für 

6. Februar 1986, Offset $18 */ 

UWORD 

os_conf; 

/* 

verschiedene Konfigurationsbits, 
Offset $1C */ 

UWORD 

os dosdate; 

/* 

TOS-Herstellungsdatum im GEMDOS- 
Format, Offset $1E */ 

/* die folgenden Felder erst 

ab TOS-Version 1.02 */ 

char 

**p_root; 

/* 

Basisadresse des GEMDOS-Pools, 
Offset $20 */ 

BYTE 

**pkbshift; 

/* 

Zeiger auf BlOS-interne Variable 
für den aktuellen Wert von 
"Kbshift 0 ", Offset $24 */ 

BASEPAGE 

**p_run; 

/* 

Adresse der Variablen, die einen 
Zeiger auf den aktuellen GEMDOS- 
Prozeß enthält, Offset $28 */ 

char 

*p rsv2; 

/* 

reserviert, Offset $2C */ 


} OSHEADER; 
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osjentry (Offset 0) 

Diese beiden Bytes enthalten ein Sprungbefehl zum Anfang der Betriebssysteminitialisierung. 
os_version (Offset 2) 

Dies ist die TOS-Versionsnummer (TOS steht übrigens entgegen immer wieder verbreiteten, 
anders lautenden Gerüchten für “The Operating System”). Folgende Betriebssystemversionen 
waren zum Zeitpunkt der Drucklegung bekannt: 

TOS 0.00 (os_version enthält $0000) war das BOOT-ROM, das mit den allerersten STs 
ausgeliefert wurde. Es war nur 64 KByte groß und diente in erster Linie zum Nachladen des 
vollständigen TOS von Diskette. Atari-interne Bezeichnung: “Das Boot”. 

TOS 1.00 (os_version: $0100) war das erste “fertige” TOS, das zunächst auf Diskette (“RAM- 
TOS”) und ab Februar 1986 auf ROMs ausgeliefert wurde (“ROM-TOS”). 

TOS 1.02 (os_version: $0102) enthält gegenüber der Vorgängerversion Routinen zur Nutzung 
des Blitters und trägt daher den Namen “Blitter-TOS”. Zuerst wurde es im Mega ST gesichtet, 
später dann aber standardmäßig auch in alle anderen Rechner eingebaut. Ebenso wie TOS 1.00 
enthält es die GEMDOS-Version 0.13, die sich durch besonders große Unzuverlässigkeit 
auszeichnet. 

Seit 1989 gibt es TOS 1.04 (os_version: $0104). Wegen des im Farbmodus mit Regenbogen¬ 
farben unterlegten Atari-Symbols im Desktop nennt es Atari “Rainbow-TOS”. TOS 1.04 
enthält ein verbessertes GEM (1.4) und ein halbwegs brauchbares GEMDOS (0.15) und ist die 
aktuellste in ST und Mega ST einsetzbare Version (wegen der Beschränkung auf 192 KByte 
ROM). 

TOS 1.06 und TOS 1.62 (os_version: $0106 bzw. $0162) sind die in den Rechnern der STE- 
Serie benutzten TOS-Versionen. TOS 1.06 ist bis auf einige Anpassungen mit TOS 1.04 
identisch. Version 1.62 enthält die verbesserte GEMDOS-Version 0.17. 

TOS-Versionen mit einer 2 vor dem Dezimalpunkt sind für Rechner der Mega-STE-Linie 
reserviert. Die bislang erste und einzige Version ist TOS 2.05 (os_version: $0205). 

Betriebssystemversionen für den TT/030 erkennt man an der 3 vor dem Dezimalpunkt.Die 
ersten ausgelieferten TTs enthielten TOS 3.01 (osjversion: $0301). Seit Anfang 1991 wird 
statt dessen das um einige kleinere Fehler korrigierte TOS 3.05 ausgeliefert. 

Originalton Atari zu TOS-Versionsnummem (Pexec-Cookbook): “Using the OS Version 
number to determine the location of undocumented variables is not acceptable. Y ou have been 
wamed.” 
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reseth (Offset 4) 

Dieser LONG-Wert zeigt auf den Beginn des Reset-Handlers. 
osjbeg (Offset 8) 

Dies ist ein Zeiger, der auf die Basisadresse des Betriebssystems zeigt. Dies kann, muß aber 
nicht die gleiche Adresse sein, auf die auch “_sysbase” zeigt. 

os_end (Offset 12) 

Zeigt auf das Ende des für BIOS, XBIOS und GEMDOS benötigte RAM. 
osjmagic (Offset 20) 

Über diesen Zeiger erhält das BIOS Informationen über das Vorhandensein und die Speicher¬ 
bedürfnisse von GEM. 

“os_magic” zeigt auf einen “GEM memory usage parameter block” folgender Gestalt: 


typedef struct 

{ 

LONG qrr. magic; 
void *gm_end; 

void 

} GEM MUPB; 


/* muß 0x87654321 sein */ 

/* Ende des von GEM benötigten 
Speicherbereichs */ 

/* Startadresse von GEM */ 


Diese Werte werden vom BIOS bei der Sy steminitialisierung ausgewertet. Wenn “gm_magic” 
den richtigen Wert hat, wird “gm_end” als “end_os” und “gm_inif ’ als “exec_os” eingesetzt. 

Anderenfalls wird für “end„os” der Wert aus “os_end” und für “exec_os” der Reset-Handler 
eingesetzt. 

Zusammen mit der XBIOS-Funktion “PuntaesO” (löscht, falls im RAM, “gm_magic”) und 
“_cmdload” ist es damit bei einer RAM-TOS-Version möglich, ohne GEM zu booten. 

Dabei werden allerdings nur der von den GEM-eigenen Variablen, nicht aber der durch den 
Programmcode belegte Speicherplatz eingespart, 

os_date (Offset 24) 

TOS-Herstellungsdatum im BCD-Format. Einige typische Werte für deutschsprachige TOS- 
Versionen: 
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Version 

os_date 

Datum 

1.00 

$02061986 

6. Februar 1986 

1.02 

$04221987 

22. April 1987 

1.04 

$04061989 

6. April 1989 

1.06 

$07291989 

29. Juli 1989 

2.05 

$12051990 

5. Dezember 1990 

3.01 

$08291990 

29. August 1990 

3.05 

$12051990 

5. Dezember 1990 


os_conf (Offset 28 ) 

Das unterste Bit enthält das NTSC/PAL-Flag (Bit gesetzt: PAL-Videosystem). In den rest¬ 
lichen Bits befindet sich eine Länderkennung, die dazu dienen kann, in kleineren Program¬ 
men automatisch die benutzte Sprache auszuwählen: 


Land 

Kürzel 

Nummer 

USA 

USA 

0 

Bundesrepublik Deutschland 

FRG 

1 

Frankreich 

FRA 

2 

Großbritannien 

UK 

3 

Spanien 

SPA 

4 

Italien 

ITA 

5 

Schweden 

SWE 

6 

Schweiz (französisch) 

SWF 

7 

Schweiz (deutsch) 

SWG 

8 

Türkei 

TUR 

9 

Finnland 

FIN 

10 

Norwegen 

NOR 

11 

Dänemark 

DEN 

12 

Saudi-Arabien 

SAU 

13 

Niederlande 

HOL 

14 


Leider gibt es einen kleinen Haken: Um einen Fehler in sehr alten AHDI-Versionen zu 
umgehen, legt TOS ab Version 1.02 einen OS-Header im RAM an und kopiert dort 
“os_dosdate” in “os_confVor dem Start der AUTO-Ordner-Programme wird dann wieder 
der “richtige” Wert eingetragen. 

Nun ist es aber so, daß alte AHDI-Versionen die restliche Systeminitialisierung selbst über¬ 
nehmen und daher nie wieder der richtige OSHEADER installiert wird. Abhilfe: Bei Zugriffen 
auf “os_conf ’ immer erst einmal indirekt über “os_beg” gehen, also zum Beispiel: 
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LONG savessp = Super (OL); 

OSHEADER *0 = *((OSHEÄDER **)(0x4f2L)); 

Super ((void *) savessp); 

O = 0->os_beg; /* wegen eines Fehlers in einer alten AHDI- 
Version */ 

So kommt man mit allen TOS- und AHDI-Versionen an den richtigen Wert. 
os_dosdate (Offset 30) 

Enthält die gleiche Information wie “os_date” - nur im GEMDOS -Format. Wird bei Rechnern 
ohne Hardware-Uhr als Startwert für die GEMDOS-Uhr benutzt. 

pjroot (Offset 32) 

Zeigt auf die “Memory free list” des GEMDOS (in TOS LOO bei Adresse $56FA). Wird von 
“FOLDR100.PRG” benutzt, um den GEMDOS-Pool zu erweitern. 

pkbshift (Offset 36) 

Zeigt auf eine ein Byte große Variable, die den aktuellen Zustand der Umschalttasten (Shift, 
Control etc.) enthält (in TOS 1.00 bei Adresse $E1B). Dies ist der Wert, der von der BIOS- 
Funktion “Kbshift(>” benutzt werden. 

“pkbshift” sollte nur dann benutzt werden, wenn der Aufruf der BIOS-Funktion nicht möglich 
ist - beispielsweise in zeitkritischen Interrupt-Routinen. 

p run (Offset 40) 

Zeigt auf einen GEMDOS-intemen Zeiger, in dem die Adresse der Basepage des aktuell 
ausgeführten GEMDOS-Prozesses steht. Mehr dazu in der GEMDOS-Einleitung. 


Systeminitialisierung 

Für viele Projekte ist es interessant zu wissen, was genau bei der Initialisierung von TOS vor 
sich geht. Die Thematik wird allerdings dadurch verkompliziert, daß es erhebliche Unterschie¬ 
de zwischen den einzelnen TOS- und Hardware-Versionen gibt und die aktuellste offizielle 
Dokumentation dazu (“Hitchhiker’s Guide to the BIOS”) noch aus dem Jahre 1985 stammt. 

Im Anfang werden Stack-Pointer und Programmzähler mit den Werten aus den Speicherzellen 
0 bis 7 geladen. Diese Adressen enthalten eine Kopie der ersten Bytes des ROMs. Der Wert 
des Stack-Pointers ist dabei eher zufällig, denn es handelt sich um die ersten vier Bytes der 
OSHEADER-Struktur (also os_entry und os_version). 
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Als nächstes werden mittels “move #$2700,sr” alle Interrupts gesperrt und eine “reset”- 
Instruktion ausgefiihrt. Siedientdazu, alle angeschlossenen Peripheriebausteine zu initialisieren. 

Wenn eine Diagnose-Cartridge eingelegt ist (dann enthält Adresse S00FA0000 den Wert 
$FA52235F), wird A6 mit einer Rücksprungadresse geladen und in den Code der Cartridge 
verzweigt (Sprung zu Adresse $0OFAOOO4). 

Nun folgt der Test auf “Warmstart”. Wenn die einzelnen Validierungsregister (“memvalid”, 
“memval2” etc.) die richtigen Werte enthalten, wird von einem “Warmstart.” ausgegangen. 
Das heißt insbesondere, daß kein neuer Speichertest durchgeführt wird. 

Als nächstes werden die im Reset-Vektor eingehängten Funktionen ausgeführt. Dazu wird 
“resvalid” auf den korrekten Wert hin überprüft, A6 mit einer Rücksprungadresse geladen und 
über “resvector” gesprungen. Wie man hier eigene Funktionen installieren sollte, wird im 
Anschluß an diesen Abschnitt beschrieben. 

Es folgt die Initialisierung verschiedener Hardwarebausteine (PSG, Shifter, DMA-Sound). 
Wenn es sich nicht um einen Warmstart handelt, wird anschließend die Größe des verfügbaren 
R AMs festgestellt, der gefundene Speicher gelöscht, und die Validierungsregister (“memvalid” 
etc.) werden initialisiert. Weitere Details zum Speichertest finden Sie im Hardwareteil. 

Nun wird der Beginn des Arbeitsspeichers gelöscht, die meisten Systemvariablen und der 
Cookie Jar initialisiert, der Bildspeicher am Ende des freien Arbeitsspeichers installiert, die 
Interrupt-Vektoren gesetzt und schließlich die BIOS-Routinen initialisiert. 

Cartridge-Software mit gesetztem Bit 26 in CA_INIT wird initialisiert und gestartet (mehr zur 
Behandlung von Cartridges im Hardwareteil). Anschließend wird (je nach Monitortyp) der 
entsprechende Shifter-Modus gesetzt, der Bildschirm initialisiertund gegebenen falls Cartridge- 
Software mit gesetztem Bit 24 in CAJNIT aufgerufen. 

Der Interrupt-Level wird auf 3 gesetzt, daß heißt, alle Interrupts bis auf den Horizontal-Blank- 
Interrupt werden eingeschaltet. Es folgt der Aufruf von Cartridge-Software mit gesetztem Bit 
25 in CA_INIT. GEMDOS wird initialisiert (das heißt: Standardkanäle werden gesetzt, interne 
Strukturen werden initialisiert, Speicherverwaltung wird übernommen etc.). 

Cartridge-Software mit gesetztem Bit 27 in CAJNIT wird initialisiert und gestartet. Nun wird 
versucht, von der Floppy zu booten. Dazu wird durch “hdv_init” und “hdv_boot” gesprungen. 

Anschließend folgt der Bootversuch von Festplatte, der je nach Hardware (ACSI und/oder 
SCSI) und TOS - Version recht verschieden aussehen kann (siehe unter “Treiber für Festplatten, 
Bootvorgang”). 
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Was jetzt kommt, ist nicht offiziell dokumentiert und sollte, wenn überhaupt, nur vorsichtig 
in kleinen Utilities benutzt werden: das BIOS durchsucht den gesamten Speicher nach einem 
512-Byte-Block (also $400, $600 etc.), der folgende Eigenschaften erfüllt: 

- Erster LONG-Wert ist die Konstante $12123456. 

- Im zweiten LONG steht ein Zeiger auf die betreffende Speicherseite. 

- Die 16-Bit-Prüfsumme aller Worte in diesem 512-Byte-Block ist $5678. 

Wenn alle diese Bedingungen erfüllt sind, dann führt das BIOS einen “jsr” zu Byte 8 der 
Speicherseite durch. Die Suche beginnt unmittelbar unter “phystop”. Zu diesem Zeitpunkt 
ist allerdings durch die GEMDOS-Initialisierung bereits aller Speicher oberhalb von $800 
gelöscht, so daß man ohne Tricks nur den Speicherbereich zwischen $600 und $7FF benutzen 
könnte. 

Nun werden die Programme im AUTO-Ordner gestartet. Dabei ist das Wurzelverzeichnis von 
“_bootdev” das aktuelle Verzeichnis. Die einzelnen Programmdateien werden also mit 
“Fsfirst (“\AUTO\*.PRG”,...)” gesucht. 

Zum Schluß wird die Default-Shell gestartet: wenn “_cmdload” nicht 0 ist, wird versucht, 
“COMMAND.PRG” auszuführen. Anderenfalls wird mehr schlecht als recht ein Default- 
Environment zusammengezimmert und über “exec_os” GEM gestartet. 

Falls dieser Schritt schiefgeht oder die Shell terminiert wird (normalerweise bei GEM nicht 
möglich), geht es zurück zum Reset. 


Der Reset-Vektor 

Was muß man tun, um eigene Funktionen in den Reset-Vektor einklinken zu können? 

1. “resvalid” muß auf die Konstante $31415926 gesetzt werden, ansonsten beachtet das 
BIOS “resvector” gar nicht erst. 

2. Der Rücksprung aus der Funktion erfolgt mit “jmp (A6)”, denn zu diesem Zeitpunkt der 
Systeminialisierung ist noch kein Stack installiert (und damit “jsr” und “rts” nicht 
möglich). 

3. Damit sich mehrere Programme installieren können, muß man sich nach Abarbeitung 
der Funktion sauber de-installieren. 
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Hier ein Beispiel dazu: 

; Installation einer Funktion im Reset-Vektor 
; nach: "Rainbow TOS Release Notes" 

; Assembler: MAS68 

RESMAGIC equ $31415926 

_resvalid equ $426 

_resvector equ $42a 

_p_cookies equ $5a0 

.text 

; eigene Funktion installieren 
install: 

move.1 __resvalid,oldvalid 
move.l #RESMAGIC,_resvalid 
move.l __resvector, oldreset 

move.l #newreset, resvector 


; dies ist die neue Funktion 

dc.b "XBRACKJR" ; XBRA-Struktur 

oldreset: 

dc.l 0 

newreset: 

; dieser Code wird während des Resets ausgeführt 

move. 1 oldreset, __resvector 
move.l oldvalid, __resvalid 
jmp (a6) 

.bss 

oldvalid: 

.ds.1 1 
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Der Vertical Blank Händler 

Einleitung 

Der Vertical-BIank-Interrupt (VBI) wird von der Video-Hardware erzeugt und liegt auf 
Interruptebene 4 (Vektor bei Adresse $70). 

In der Interrupt-Hierarchie nimmt er damit einen Platz über dem Horizontal-Blank (der beim 
ST normalerweise nicht benutzt wird) und unterhalb der MFP-Interrupts ein. 

Der VBI tritt jeweils beim vertikalen Zeilenrücklauf des Elektronenstrahls auf und ist damit 
besonders für die Manipulation von Registern in der Video-Hardware geeignet (da man sonst 
mit Störungen auf dem Bildschirm rechnen müßte). 

Daher tritt er - je nach verwendetem Video-System - zwischen 50 und 72 mal pro Sekunde 
auf. 

Die folgende Beschreibung der vom BIOS installierten Vertical-Blank-Routine erhebt weder 
Anspruch auf Korrektheit noch auf Vollständigkeit. Speziell in neuen BlOS-Versionen 
können sich Unterschiede bei der Reihenfolge ergeben! 

1. Zunächst wird der Zähler “_frclock” inkrementiert. 

2. Falls “vblsem” kleiner oder gleich 0 ist, wird die Interruptroutine beendet. 

3. Alle Register werden gerettet. 

4. “_vbclock” wird inkrementiert. 

5. Falls die aktuelle Auflösung “hoch” ist (bei ST und STE: Auflösung 2, beim TT: Auf¬ 
lösung 6) und nicht der entsprechende Bildschirm angeschlossen ist, wird die Auflösung 
auf “defshiftmd” gesetzt und durch den Vektor “swv_vec” gesprungen. 

6. Die VT52-Cursor-Blink-Routine wird aufgerufen. 

7. Wenn “colorptr” ungleich 0 ist, wird die dort eingetragene Farbpalette in die Farbregister 
der Video-Hardware übertragen und “colorptr” anschließend wieder gelöscht. 

8. Wenn “screenpt” ungleich 0 ist, wird die dort eingetragene Adresse in “_v_bas_ad” und 
die dazugehörigen Hardwareregister übertragen und “screenpt” nicht wieder gelöscht. 
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9. Die “deferred” Vertical-Blank-Routinen werden nacheinander aufgerufen (mehr dazu 
im Anschluß). 

10. Falls “prt_cnt” nicht 0 ist, wird durch “scr_dump” gesprungen (und dabei normalerweise 
eine Hardcopy ausgegeben). 

11. Die geretteten Registerinhalte werden wiederhergestellt. 


“Deferred” Vertical-Blank-Routinen 

Mit den beiden System variablen “nvbls” ($454) und “_vblqueue” ($456) hat man die 
Möglichkeit, eigene Funktionen in die System-VBI-Routine einzuklinken. Dazu durchsucht 
man die Tabelle, auf die “„vblqueue” zeigt, nach freien Einträgen (also nach Einträgen, die 
Nullzeiger enthalten). 

Ist kein freier Platz da (Anzahl der Plätze steht in “nvbls”), reserviert man Platz für eine eigene 
Tabelle, kopiert die bestehende dorthin und fügt die eigene Routine hinten an. Anschließend 
muß man noch die beiden Systemvariablen aktualisieren. 


Warnung: Dreisterweise überschreibt GEM bei der Initialisierung den Vektor für die erste 
Vertical-Blank-Routine durch den Zeiger für die Mausbewegungs-Routinen. Soll ein im 
AUTO-Ordner installierter Interrupt diesen Anschlag überleben, muß man bei der Suche nach 
einer freien Adresse die erste Adresse überspringen (der Klügere gibt nach...). Der Grund dafür 
liegt wahrscheinlich darin, daß vermieden werden sollte, daß bei der erneuten Initialisierung 
(nach Wechseln der Auflösung) eine zweite Vertical-Blank-Routine installiert wird. 


Hier ein Beispiel: 

; VBLank installieren 


move.w nvbls,dO 

lsl.w #2,d0 

move.1 _vblqueue,aO 

moveq #4, dl 

search__vb_slot: 

tst.l (aO/dl) 

beq slot_found 

addq #4, dl 

cmp.w dO,dl 

bne search vb slot 


mal 4 

einen Eintrag überspringen 
frei? 


Ende erreicht? 
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; Fehler melden 
clr.w dO 

rts 

slot_found: 

move.l #MyVB,0(a0,dl) ; VBlank-Handler eintragen 

; und weiter... 


Feste Adressen im System 


Einleitung 

Die untersten zwei Kilobytes des Arbeitsspeichers nehmen im Atari eine besondere Rolle ein: 
die Belegung der meisten Speicheradressen ist dokumentiert und darf unter Beachtung einiger 
Vorsichtsmaßnahmen auch verändert werden. 

Im einzelnen handelt es sich um 

Vektoren für Systeminterrupts (ab Byte 8 aufwärts) und 

- die eigentlichen Systemvariablen (ab $380 aufwärts). 

Der Zugriff auf diesen Speicherbereich ist nur aus dem Supervisor-Modus heraus möglich. 

Die Systemvariablen und -vektoren sind die absolut “unterste” Schicht des Betriebssystems. 
Anwendungsprogramme sollten schon in Hinsicht auf mögliche Multitasking-Erweiterungen 
des Betriebssystems (wie zum Beispiel “Multi-GEM” von Maxon) niemals auf diese Spei¬ 
cherbereiche zugreifen. Nur kleine Utilities und Programme, die unter die Rubrik “Systemsoft¬ 
ware” fallen, sollten sich hier zu schaffen machen. 

Also: 

- Niemals Systemvariablen verändern, die laut Atari nicht verändert werden dürfen. 

- Niemals Systemvariablen benutzen, wenn statt dessen auch eine Betriebssystemfunktion 
in Frage käme (siehe zum Beispiel “SetexcO” und “MfpintO”). 


Immer sauber zwischen Anwendungsprogrammen und kleinen Utilities oder System¬ 
software trennen. 
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Liste der Systemvektoren 

LONG $000 0 Reset: SSP 

Man sollte es nicht glauben, aber diese und die folgenden Speicherzellen enthalten ROM - 
und zwar eine Spiegelung der ersten acht Bytes des ROMs. 

Bei einem RESET (durch Tastendruck oder Einschalten des Rechners) wird der hier liegende 
Wert in den Supervisor-Stack-Pointer geladen (allerdings kein sinnvoller - der “richtige” 
Stack wird erst später vom BIOS installiert). 

LONG $004 4 Reset: PC 

Bei RESET wird der hier Vorgefundene Wert in den Program-Counter geladen. Man findet 
hier also die Adresse, die bei einem RESET angespmngen wird. 

LONG $008 8 Busfehler 

Exception-Vektor 2: zwei Bömbchen. 

Busfehler treten auf, wenn man versucht, auf Speicherbereiche zuzugreifen, auf die kein 
Zugriff erlaubt ist. Das können im Supervisor-Modus eigentlich nur nicht existierende 
Speicherbereiche sein. Im User-Modus kann es auch beim Zugriff auf Hardware-Register oder 
Bereiche unterhalb von $800 passieren. 

Im Normalfall zeigt dieser Vektor auf die TOS-Routinen zur Anzeige von Bömbchen (in 
diesem Fall zwei an der Zahl). 

LONG $00C 12 Adreßfehler 

Exception-Vektor 3: drei Bömbchen. 

68000 und 68010 können nur byteweise auf ungerade Adressen zugreifen. Diese Exception 
wird ausgelöst, wenn man dennoch einen Wort- oder Langwort-Zugriff versucht (auch Pro¬ 
grammzähler und Stack-Pointer dürfen keine ungeraden Werte enthalten!). 

LONG $010 16 Illegaler Befehl 

Exception-Vektor 4: vier Bömbchen. 

Es wurde versucht, einen illegalen Befehl auszuführen. Dieser Vektor wird von vielen 
Debuggern zur Verwendung für Break-Points geändert. 
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LONG $014 20 Division durch Null 

Exception-Vektor 5: kein Bömbchen. 

Bei einem DIV-Befehl wurde durch 0 geteilt. 

Dieser Vektor zeigt im Normalfall auf einen “RTE”-Befehl (Retum from exception); daher 
gibt es auch keine Bömbchen. 

LONG $018 24 CHK-Befehl 

Exception-Vektor 6 

Es wurde eine Exception durch einen “CHK”-Befehl erzeugt. 

LONG $01C 28 Befehl TRAPV 

Exception-Vektor 7 

Es wurde eine Exception durch einen “TRAPV”-Befehl erzeugt, 

LONG $020 32 Privilegverletzung 

Exception-Vektor 8 

Es wurde versucht, einen Befehl auszuführen, der nur im Supervisor-Modus erlaubt ist. 

Beim TT testet das BIOS, ob es sich bei dem betreffenden Befehl um einen “move sr,...” 
gehandelt hat: dieser Befehl ist im Gegensatz zum 68000er nur im Supervisor-Modus erlaubt. 
In einem solchen Fall setzt das BIOS statt dessen einen “move ccr,..” ein und versucht, das 
Programm weiterlaufen zu lassen. 

LONG $024 36 Trace 

Exception-Vektor 9 

Ist das TRACE-Bit im Statusregister gesetzt, wird nach jeder Instruktion die hier angegebene 
Adresse angesprungen. 


LONG $028 40 Line-A-Vektor 

Exception-Vektor 10 
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Es wurde versucht, eine Instruktion auszuführen, die in den obersten vier Bits den Wert “$ A" 
enthält. Zur Zeit wird dieser Vektor für die “Line-A-Routinen” benutzt (siehe unter VDI- 
Gerätetreiber). 

LONG $02C 44 Line-F-Vektor 

Exception-Vektor 11 

Es wurde versucht, eine Instruktion auszuführen, die in den obersten Bits den Wert “$F” 
enthält. 

Wird bis TOS 1.04 vom GEM benutzt und ist eigentlich für die Programmierung der Floating- 
Point-Unit gedacht. 

LONG $030 48 Reserviert 

- $05C 92 

Exception-Vektoren 12-23 

LONG $060 9 Spurious Interrupt 

Exception-Vektor 24 

Tritt auf, wenn ein Interrupt ausgelöst wurde, die Ursache dafür aber nicht feststellbar war. 

LONG $064 100 Autovektor-Interrupt, Level 1 

Unbenutzt. 

LONG $068 104 Autovektor-Interrupt, Level 2 

Zeigt auf den Händler für Horizontal-Blanks. 

LONG $06C 108 Autovektor-Interrupt, Level 3 

Unbenutzt. 

LONG $070 112 Autovektor-Interrupt, Level 4 

Zeigt auf den Händler für Vertical-Blanks. 
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LONG $074 116 Autovektor-Interrupt, Level 5 

Unbenutzt. 

LONG $078 120 Autovektor-Interrupt, Level 6 

Zeigt auf Händler für MFP-Interrupts. 

LONG $07C 124 Autovektor-Interrupt, Level 7 

Unbenutzt. 

LONG $080 128 TRAP#ü 

Exception-Vektor 32 

Vektor für den Befehl “TRAP #0”. Da vom Betriebssystem nicht benutzt, gibt es Bömbchen. 

LONG $084 132 TRAP#1 

Exception-Vektor 33 

Vektor für den Befehl “TRAP #1”. Zeigt auf den Dispatcher für die GEMDOS-Funktionen. 

LONG $088 136 TRAP #2 

Exception-Vektor 34 

Vektor für den Befehl “TRAP #2”. Wird von AES und VDI benutzt. 

LONG $08C 140 TRAP #3 

-$0B0 -176 TRAP #12 

Exception-Vektoren 35 bis 44: Entsprechend viele Bömbchen, da sie zurZeit vom Betriebssystem 
nicht benutzt werden. 

LONG $0B4 180 TRAP #13 

Exception-Vektor 45 

Vektor für den Befehl “TRAP #13”. Zeigt auf den Dispatcher für die BIOS-Funktionen. 
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LONGSOB8 184 TRAP #14 

Exception-Vektor 46. Vektor für den Befehl “TRAP #14”. Zeigt auf den Dispatcher für die 
XBIOS-Funktionen. 


LONG $0BC 188 TRAP #15 

Unbenutzt. 

LONG $0C0 192 Reserviert 

- $0FC -252 

Exception-Vektoren 48 - 63 

LONG $100 256 BUSY Interrupt 

ST-MFP-Interrupt 0. Wird durch parallele Schnittstelle ausgelöst. Normalerweise nicht 
benutzt. 

LONG $104 260 DCD Interrupt 

ST-MFP-Interrupt 1. Wird durch die serielle Schnittstelle (“Carrier detect”) ausgelöst. 
Normalerweise unbenutzt. 

LONG $108 264 CTS Interrupt 

ST-MFP-Interrupt 2. Wird durch die serielle Schnittstelle (“Clear to send”) ausgelöst. 
Normalerweise unbelegt. 

LONG $10C 268 GPU Done 

ST-MFP-Interrupt 3. Kann vom Blitter benutzt werden, um den Abschluß einer Operation 
anzuzeigen. Normalerweise nicht benutzt, 

LONG $110 272 Baudratengenerator 

ST-MFP-Interrupt 4. Normalerweise nicht benutzt. 

LONG $114 276 200 Hz System Timer 

ST-MFP-Interrupt 5. Zeigt auf den Systemtimer-Interrupt und darf auf keinen Fall verändert 
werden (wird für Timing-Schleifen im TOS benötigt!). 
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LONG $118 280 IKBD/MIDI 

ST-MFP-Interrupt 6. Zeigt auf den Händler für IKBD- und MIDI-Interrupts. 

LONG $11C 284 FDC/ACSI 

ST-MFP-Interrupt 7. Normalerweise unbelegt. 

LONG $120 288 Display Enable Signal 

ST-MFP-Interrupt 8. Normalerweise gesperrt. 

LONG $124 292 RS232 Sendefehler 

ST-MFP-Interrupt 9. Wird bei Übertragungsfehlem beim Senden von Daten über die serielle 
Schnittstelle ausgelöst. 

LONG $128 296 RS232 Sendepuffer leer 

ST-MFP-Interrupt 10. Wird ausgelöst, wenn der Sendevorgang eines einzelnen Bytes 
abgeschlossen worden ist. 

LONG $12C 300 RS232 Empfangsfehler 

ST-MFP-Interrupt 11. Tritt bei Empfangsfehlem auf. 

LONG $130 304 RS232 Empfangspuffer voll 

ST-MFP-Interrupt 12. Ein komplettes Zeichen ist von der seriellen Schnittstelle empfangen 
worden. 

LONG $134 308 - 

ST-MFP-Interrupt 13. Unbenutzt. 

LONG $138 312 Ring Indicator 

ST-MFP-Interrupt 14. Wird ausgelöst, wenn die serielle Schnittstelle einen ankommenden 
Anruf bemerkt (z. B. bei Verwendung von Modems). Da dieser Interrupt so leicht auszulösen 
ist (entweder mit einem speziellen Schalter an der RS232-Schnittstelle oder oft - bei 
angeschlossenem Modem - durch Aus- und Einschalten des Modems), wird er gerne in 
Debuggern als Break-Signal benutzt. 
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LONG $13C 316 Monochrom Monitor Detect 

ST-MFP-Interrupt 15. Unbenutzt. 

LONG $140 320 TT-MFP-Interrupts 

- $17C 380 

16 Interruptvektoren für den zweiten MFP im TT. 

LONG $180 384 TT-SCC-Interrupts 

- $1BC 444 

Platz für die Interruptvektoren des TT-SCC-Bausteins. 


Post-Mortem-Informationen 

Bei einem Systemabsturz versucht das BIOS, noch Informationen über die Art des Problems 
auszugeben und das System wieder halbwegs in Ordnung zu bringen. 

Zu den Maßnahmen gehören: 

Je nach Exceptionnummer wird in der Bildschirmmitte eine Reihe vonBombensy mbolen 
ausgegeben. Dies natürlich per direktem Bildschirmzugriff, VDI-Funktionen können in 
diesem Moment natürlich nicht aufgerufen werden. 

- Im Speicherbereich von $380 bis $3FF werden die aktuelle Registerbelegung und Teile 
des Stacks gerettet. 

Der vom BIOS-Dispatcher benötigte “savptr” wird zurückgesetzt. 

- Das Programm wird mit “Pterm (-1)” beendet. 

Und noch ein paar Anmerkungen: 

- Jede dieser Aktionen kann natürlich in Unglücksfällen zu weiteren Exceptions führen. 
Resultat sind dann die verhaßten “Bombengirlanden”. 

- Der BIOS-Dispatcher ignoriert Exception Nummer fünf (Division durch 0). So bleiben 
unter Umständen einige Programmfehler unbemerkt. 
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- Der 68030 ist nicht hundertprozentig zum 68000 kompatibel. So gibt es beispielsweise 
einen Befehl, der auf dem 68000 im User-Modus erlaubt ist, auf dem 68030 allerdings 
mit einer “privilege violation” quittiert wird. Das TT-BIOS kompensiert dies durch einen 
speziellen Exception-Handler, der versucht, den Befehl sinnvoll zu emulieren. 

Und hier die vom Exception-Handler benutzten Systemvariablen: 

LONG $380 896 procjives 

Wenn in dieser Adresse die magische Zahl (“magic number”) $ 12345678 steht, sind die in den 
folgenden Adressen vorliegenden Informationen gültig. 

LONG $384 900 procdregs 

- $3a0 928 

In diesen Adressen werden im Falle einer Exception, die Bömbchen hervorruft, folgende 
Register gerettet: 

DO, Dl, D2, D3, D4, D5, D6, D7 

LONG $3A4 932 procaregs 

- $3C0 960 

In diesen Adressen werden im Falle einer Exception, die Bömbchen hervorruft, folgende 
Register gerettet: 

A0, Al, A2, A3, A4, A5, A6, A7’ (Supervisor-Stack-Pointer) 

BYTE $3C4 964 procenum 

Nummer der aufgetretenen Exception. 

LONG $3C8 968 proc jisp 

Geretter Wert des User-Stack-Pointers. 

WORD $3CC 972 proc_stk 

Die obersten sechzehn Worte des Stacks beim Auftreten der Exception. 
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Liste der Systemvariablen 
LONG $400 1024 etvtimer 

Logischer GEMDOS-Vektor 256 (siehe Einleitung zum GEMDOS). Sollte immer nur mittel s 
“Setexc()” gesetzt werden. 

LONG $404 1028 etvcritic 

Logischer GEMDOS-Vektor 257 (siehe Einleitung zum GEMDOS). Sollte immer nur mittels 
“SetexcO” gesetzt werden. 

LONG $408 1032 etvjerm 

Logischer GEMDOS-Vektor 258 (siehe Einleitung zum GEMDOS). Sollte immer nur mittels 
“SetexcO” gesetzt werden. 

LONG $40C 1036 etvxtra 

Reserviert für die logischen GEMDOS-Vektoren 259 bis 263 (zur Zeit nicht benutzt). 

LONG $420 1056 memvalid 

Sollte die magische Zahl $752019F3 enthalten. 

Siehe auch “memval2”, “memval3” und “memcntrl”. 

BYTE $424 1060 memcntrl 

Enthält die untersten vier Bits des Speicherkontroll-Registers ($FFFF8001). 

LONG $426 1062 resvalid 

Wenn diese Adresse bei RESET den Wert $31415926 enthält, wird durch “resvector” 
gesprungen. 

LONG $42A 1066 resvector 

Wird bei der Systeminitialisierung benutzt. Enthält den Vektor für RESET, falls “resvalid” 
den korrekten Wert beinhaltet. Zum Zeitpunkt des Aufrufs sind die Hardwareregister noch 
nicht gesetzt, und auch der Stack-Pointer ist noch nicht initialisiert. 
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LONG $42E 1070 phystop 

Zeiger auf das erste Byte über dem physikalischen Ende des ST-kompatiblen RAM-Bereichs 
(zum Beispiel $00010000 bei 1MB RAM). 

LONG $432 1074 membot 

Unteres Ende des unter GEMDOS freien ST-kompatiblen Speichers (also Anfang der 
“ursprünglichen” TPA). Wird von der BIOS-Funktion “GetmpbO” verwendet. 

LONG $436 1078 memtop 

Analog zu “_membot” das Ende des freien ST-kompatiblen Speicherbereichs. 

LONG $43A 1082 memval2 

Sollte die Magic Number $237698AA enthalten. Haben sowohl “memval2” als auch 
“memvalid” (und ab TOS 1.02 “memval3”) den geforderten Wert, wird beim nächsten RESET 
nur ein Warmstart durchgeführt. 

WORD $43E 1086 flock 

Wenn hier ein Wert ungleich 0 steht, dann darf nicht auf den DMA-Chip zugegriffen werden. 
DMA-Gerätetreiber müssen also zunächst abfragen, ob der DMA-Chip blockiert worden ist, 
und “flock” dann, wenn sie mit der Arbeit beginnen, selbst setzen. 

WORD $440 1088 seekrate 

Seekrate für die beiden Floppies. Erlaubte Werte: 


Wert 

Seekrate 

0 

6ms 

1 

12ms 

2 

2ms 

3 

3ms 


Diese Systemvariable wird gleich nach dem Systemstart vom BIOS (durch den Aufruf der in 
“hdv_init” eingetragenen Routine) ausgelesen und danach ignoriert. 

Zum Ändern der tatsächlich benutzten Seekrate muß man die XBIOS-Funktion “FloprateO” 
verwenden. 
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WORD $442 1090 _timr_ms 

Zeit in Millisekunden, die normalerweise zwischen zwei Aufrufen des System-Timers vergeht 
(liegt daher bei 20; wg. 50 Hz). Dieser Wert wird auch von der BIOS-Funktion “TickcalO” 
zurückgeliefert. 

WORD $444 1092 Jverify 

Legt fest, ob das BIOS beim Schreiben auf Diskette per “RwabsO” einen Verify durchgeführen 
soll (0 bedeutet: kein Verify). Im Normalfall ist Verify eingeschaltet. 

WORD $446 1094 bootdev 

Enthält normalerweise die Nummer des Laufwerks, von dem gebootet worden ist. 

Das BIOS benutzt diese Variable, um den Standardzugriffspfad für die Environmentvariable 
“PATH” zu ermitteln. In allen bekannten TOS-Versionen greift es dazu allerdings auf das 
höherwertige Byte zu, so daß zumindest an dieser Stelle immer “A:\” herauskommt. 
Harddisktreiber von Fremdherstellem beheben dieses Problem meist. 

Mit dem Atari-Festplattentreiber fällt es nicht weiter auf, da die AES-Accessories immer auf 
Laufwerk C: suchen, falls dieses existiert (und von anderen Partitionen kann man mit AHDI 
sowieso nicht booten). 

Daneben wird diese Variable auch noch beim Booten benutzt, um das Bootlaufwerk zu wählen 
(das klappt im allgemeinen aber nur dann, wenn kein Festplattentreiber gebootet wird). 

Wenn man also “_bootdev” auf 1 setzt, keine autobootende Festplatte angeschlossen hat und 
einen Reset auslöst, wird von Laufwerk B: gebootet. 

WORD $448 1096 palmode 

Legt laut Atari die Femsehnorm fest. 

Die Werte: 

0: NTSC-Modus (60 Hz) 

sonst: PAL-Modus (50 Hz) 

Tatsächlich wird diese Systemvariable nicht berücksichtigt. Eine Änderung der Bildwieder¬ 
holfrequenz ist nur über die entsprechenden Hardwareregister möglich. 
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BYTE $44A 1098 defshiftmd 

Standard-Farbgraflk-Auflösung. Schaltet der Computer auf Farbbetrieb um (nach RESET 
durch Wechseln der Stecker oder Einschalten), wird in die angegebene Auflösung geschaltet. 


BYTE $44C 1100 sshiftmd 

Kopie des Modus-Registers des Shifters ($FFFF8260). Die Werte: 


Wert 


Bildgröße 


0 

1 

2 

4 

6 

7 


320 *200 
640 * 200 
640 *400 
640 *480 
1280*960 
320 *480 


(vier Planes) 

(zwei Planes) 

(ein Plane) 

(vier Planes, nur beim TT) 
(ein Plane, nur beim TT) 
(acht Planes, nur beim TT) 


Alle anderen Werte sind für künftige Erweiterungen reserviert. 


LONG $44E 1102 _v_bas_ad 

Zeiger auf den Anfang des Bildspeichers, der beim ST auf einer 256-Byte-Grenze beginnen 
muß (Sorry, kein Raum für großartige Tricks für Fine-Scrolling). Beim STE und TT ist es eine 
2- bzw. 8-Byte-Grenze. 

Dies ist der Wert, der normalerweise von “LogbaseO” zurückgeliefert wird. 


WORD $452 1106 vblsem 

1: Vertical-Blank-Handler aktiviert. 

WORD $454 1108 nvbls 

Anzahl der Einträge, auf die “_vblqueue” zeigt. Identisch mit der Maximalzahl von 
gleichzeitig installierbaren Vertical-Blank-Routinen. Standardwert ist 8. 


LONG $456 1110 vblqueue 

Zeiger auf Zeigertabelle für Vertical-Blank-Prozesse. 
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LONG $45A 1114 colorptr 

Zeiger auf eine Farbpalette, die beim nächsten Vertical Blank in die ST-Hardware-Farbregister 
geladen wird (ab Adresse $FFFF8240). Damit wird ein unschönes Zucken auf dem Bildschirm 
vermieden. Steht in “colorptr” eine Null, passiert gar nichts. Nach der Übertragung der Farb¬ 
werte wird “colorptr” gelöscht. 

Besser ist es, die entsprechenden VDI-Funktionen zu nutzen, da schon beim “Atari TT” die 
Farbpalette mehr als 16 Einträge umfassen kann. Bei anderen Grafikkarten wird diese Variable 
ganz ignoriert. 


LONG $45E 1118 screenpt 

Zeiger auf den Anfang des Bildspeichers. Wird beim nächsten Vertical Blank in die 
betreffenden Hardwareregister übertragen, anschließend aber nicht gelöscht (daher sollte man 
statt dessen immer mit “SetscreenQ” arbeiten!). 


LONG $462 1122 _vbclock 

Anzahl der bereits erfolgten Vertical Blanks. 

LONG $466 1126 Jrclock 

Wie “„vbclock”, mit dem Unterschied, daß die Zählung nicht durch “vblsem” angehalten 
wird. 


LONG $46A 1130 hdvjnit 

Vektor zu den Initialisierungsroutinen für die Diskettenlaufwerke. Wird vor dem Lesen der 
Bootsektoren ausgelesen und kann daher nur von reset-residenten Programmen oder ROM- 
Modulen verändert werden. 

Zu den Aufgaben gehören: 

- Initialisierung der Diskettenlaufwerke (“_nflops” wird entsprechend gesetzt) 

- Übertragung von “seekrate” in die BlOS-intemen Variablen 

LONG $46E 1134 swv_vec 

Zeiger auf die Routine, die auf das Anschließen eines Schwarzweiß- bzw. Farbmonitors 
reagiert (zeigt zu Beginn auf die normale RESET-Routine). 
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LONG $472 1138 hdvjbpb 

Vektor zur Routine, die den BPB (BIOS Parameter Block) eines BIOS-Laufwerks ermittelt. 
Auf dem Stack (4(sp)) wird die BIOS-Gerätenummer übergeben. 

In DO liefert man entweder einen Zeiger auf den BPB oder im Fehlerfall 0 zurück. 

LONG $476 1142 hdv_rw 

Vektor zur Routine zum Lesen und Schreiben von Blöcken auf BIOS-Laufwerken. Auf dem 
Stack werden die gleichen Parameter wie bei “RwabsO” übergeben (beginnend mit 4(sp): 
rwflag). 

In DO liefert man den Retum-Wert für “RwabsO” zurück (beispiel weise 0, wenn alles geklappt 
hat). 

LONG $47A 1146 hdvjboot 

Vektor zur Routine zum Laden des Bootsektors. Diese Routine wird vom BIOS benutzt, um 
festzustellen, ob ein Bootsektor vorhanden und ob er ausführbar ist. 

LONG $47E 1150 hdv mediach 

Vektor zur Routine zur Bestimmung des Medienwechsel-Status eines BIOS-Laufwerks. Auf 
dem Stack (4(sp)) wird die BIOS-Gerätenummer übergeben. 

In DO liefert man den Retum-Wert für “MediachO” zurück. 

WORD $482 1154 _cmdload 

Wenn dieses Register nicht 0 ist, wird versucht, anstelle von GEM das Programm “COM- 
MAND.PRG” zu starten (kann durch ein Programm in einem ausführbaren Bootsektor gesetzt 
werden). 


BYTE $484 1156 conterm 

Attributbits für BIOS-Gerät “CON:”: 


Bit 

Bedeutung 

0 

Tastenklick (Keyclick) ein/aus 

1 

Tastenwiederholung ein/aus 
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Bit 


Bedeutung 


2 Glocke (Ping!) bei Ausgabe von CTRL-G 

3 Bei “Bconin(>” aktuellen Wert von “KbsbiftO” in den Bits 24..31 zurückgegeben 


LONG $486 1158 trpl4ret 

Offiziell nicht dokumentiert und wohl auch unbenutzt. 


LONG $48A 1162 criticret 

Offiziell nicht dokumentiert und wohl auch unbenutzt. 


MD $48E 1166 themd 

MD-Struktur des GEMDOS. 

Diese wird ein einziges Mal bei der Initialisierung des Systems gesetzt und darf nicht verändert 
werden (und das wird sie durch Benutzung der BIOS-Funktion “GetmpbO”!). 

LONG $49E 1182 _md 

Offiziell nicht dokumentiert und wohl auch unbenutzt. 

LONG $4A2 186 savptr 

Zeiger auf Register-Zwischenspeicher von BIOS und XBIOS. Mehr dazu bei der Dokumen¬ 
tation des BIOS- bzw. XBIOS-Bindings. 

WORD $4A6 1190 jnflops 

Anzahl der angeschlossenen Diskettenlaufwerke (0, 1 oder 2). 

LONG $4A8 1192 con_state 

Interner Zeiger für Bildschirmausgaberoutinen; offiziell nicht dokumentiert. 

WORD $4AC 1196 sav_row 

Interner Puffer zur Zwischenspeicherung der Cursor-Position; offiziell nicht dokumentiert. 
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LONG $4AE 1198 sav_context 

Sollte eigentlich ein Zeiger auf den Speicherbereich sein, in den bei Exceptions die Register 
und Teile des Stacks gerettet werden. Tatsache aber ist, daß er vom TOS nicht benutzt wird 
und daß man daher direkt auf die Variablen bei Adresse $380 zugreifen muß. 

LONG $4B2 1202 bufl 

Zwei Zeiger auf GEMDOS-Pufferlisten. Mehr dazu in der Einführung zum GEMDOS. 

LONG $4BA 1210 hz_200 

Bisherige Anzahl der 200-Hz-Interrupts. 

LONG $4BE 1214 the_env 

Zeiger auf die Standard-Environment-Strings (unbenutzt!). 

LONG $4C2 1218 _drvbits 

Bit-Tabelle über die angemeldeten BIOS-Laufwerke (Bit Null für Laufwerk “A:” etc.). Hier 
ist also Platz für 32 Einträge! Diese Variable wird im TOS 1.00 beim Reset nicht gelöscht. 
Eigene Treiber sollten daher bei einem Reset die selbst eingetragenen Bits löschen, Ansonsten 
kann es passieren, daß Laufwerkskennungen “verschwinden” (viele Treiber installieren sich 
immer auf der ersten “freien” Gerätenummer). 

LONG $4C6 1222 _dskbufp 

Zeiger auf einen 1024 Bytes großen Puffer zum Lesen und Schreiben auf Disketten oder 
Festplatten (z. B. beim Bootversuch). Wird auch vom VDI verwendet. 

LONG $4CA 1228 autopath 

Zeiger auf Zugriffspfad für AUTO-Ordner (unbenutzt und nicht offiziell dokumentiert). 
LONG $4CE 1232 „vbljist 

Ursprüngliche Liste der Vertical-Blank-Routinen (immer nur über “„vblqueue” zugreifen!). 

WORD $4EE 1262 prtcnt 

Zähler für die ALT-HELP-Tastendrücke: 
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Wert 

Bedeutung 

-1: 

normaler Status 

0: 

Hardcopy beginnen 

>0: 

Hardcopy abbrechen und auf -1 zuriicksetzen 


Diese Variable muß man auch vor einem Aufruf von “PrtblkQ” setzen! 


WORD $4F0 1264 _prtabt 

Flag für Abbruch des Druckvorgangs (unbenutzt). 


LONG $4F2 1266 _sysbase 

Zeiger auf eine Struktur folgender Form: 


typedef struct 
{ 

osheader 


UWORD 

os_entry; 

/* 

UWORD 

os_version; 

/* 

void 

*reseth; 

/* 

struct __osheader 
*os_beg; 

/* 

void 

*os end; 

/* 

LONG 

os_rsvl; 

/* 

GEM_MUPB 

*os_magic; 

/* 

LONG 

os date; 

/* 

UWORD 

os_conf; 

/* 

UWORD 

os_dosdate; 

/* 


BRAnch-Instruktion zum RESET- 
Handler, Offset $00 */ 
TOS-Versionsnummer, Offset $02 */ 
Zeiger auf RESET-Handler, 

Offset $04 */ 

Basisadresse des Betriebssystems, 
Offset $08 */ 

Erstes nicht vom OS benutztes 
Byte, Offset $0C */ 
reserviert, Offset $10 */ 

Zeiger auf "GEM memory usage 
Parameter block", Offset $14 */ 
TOS-Herstellungsdatum im BCD- 
Format, etwa $02061986 für 
6. Februar 1986, Offset $18 */ 
verschiedene Konfigurationsbits, 
Offset $1C */ 

TOS-Herstellungsdatum im GEMDOS- 
Forxrat, Offset $1E */ 


/* die folgenden Felder erst ab TOS-Version 1.02 */ 
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char 

**p_root; 

/* 

Basisadresse des GEMDOS-Pools, 
Offset $20 */ 

BYTE 

**pkbshift; 

/* 

Zeiger auf BlOS-interne Variable 
für den aktuellen Wert von 
"Kbshift()", Offset $24 */ 

BASEPAGE 

**p run; 

/* 

Adresse der Variablen, die einen 
Zeiger auf den aktuellen GEMDOS- 
Prozeß enthält,Offset $28 */ 

char 

OSHEADER; 

*p rsv2; 

/* 

reserviert, Offset $2C */ 


Zum “OS-Header” gibt es viel zu sagen und deshalb auch einen eigenen Abschnitt (direkt vor 
diesem!). 

LONG $4F6 1270 _shell_p 

Dieser Zeiger wird vom ROM nicht genutzt. Das heißt: Programme, die ihn selbst benutzen, 
müssen ihn im Falle eines Resets und natürlich auch bei Programmbeendigung löschen! 

Normalerweise wird “_shell_p” von UNIX-ähnlichen Shells gesetzt und zeigt auf eine 
Routine, die eine Kommandozeile abarbeitet. Die Adresse der Zeichenkette wird auf dem 
Stack (4(sp)) übergeben, das Ergebnis der Operation erhält man in Register DO. Die meisten 
C-Libraries enthalten ein Binding für die Standardfunktion “systemQ”, das in etwa so aussieht: 

/* WORD System (const char *cmd) 

Führt das Kommando "cmd" über die in _shell_p installierte 
Shell aus. 

Wenn "cmd" ein Nullzeiger ist, wird festgestellt, ob eine Shell 
installiert ist. Ansonsten wird die Zeile übergeben und der 
Return-Wert der Shell zurückgeliefert. 

*/ 

#define _SHELL_P ((LONG *)0x4f6L) 

WORD System (const char *cmd) 

{ 

WORD cdecl (*do_sys)(const char *cmd); 

LONG oldssp; 

oldssp = Super (OL); 

do_sys = (void (*))*_SHELL_P; 

Super ((void *)oldssp); 
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if <!cmd) 

return (do_sys != OL); 

if <do_sys != OL) 

return do_sys (cmd); 


Was in der Kommandozeile stehen kann, ist natürlich von der benutzten Shell abhängig. Bei 
allen in Frage kommenden Shells handelt es sich allerdings um UNIX-ähnliche Shells, so daß 
man davon ausgehen kann, daß UNIX-übliche Standardkommandos und auch eigene, zusätz¬ 
lich installierte TOS-Programme gestartet werden können. 

LONG $4FA 1274 endos 

Zeiger auf das erste nicht für TOS-inteme Variablen benutzte Byte (also das erstes Byte des 
freien Speichers). 

LONG $4FE 1278 exec_os 

Zeiger auf das erste Byte des Textsegments des Shell-Programms. 

Das Shell-Programm wird nach der vollständigen Initialisierung von GEMDOS und dem 
Abarbeiten des AUTO-Ordners mittels “Pexec()” gestartet (normalerweise AES und Desktop). 

LONG $502 1282 scr_dump 

Zeiger auf Hardcopyroutine (wird von der XBIOS-Funktion “ScrdmpQ” benutzt). 

LONG $506 1286 prvJsto 

Zeiger auf Routine zum Feststellen des Status des parallelen Ports (ebenfalls für Hardcopy- 
Routine). 

LONG $50A 1290 prvjst 

Zeiger auf Routine zur Ausgabe auf dem parallelen Port (ebenfalls für Hardcopy-Routine). 
Das auszugebende Zeichen steht in 6(sp). 
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LONG $50E 1294 prvauxo 

Zeiger auf Routine zum Feststellen des Status der seriellen Schnittstelle (ebenfalls für 
Hardcopy-Funktion). 

LONG $512 1298 prv aux 

Zeiger auf Routine zur Ausgabe auf dem seriellen Port (ebenfalls für Hardcopy-Routine). Das 
auszugebende Zeichen steht in 6(sp). 


LONG $516 1302 punjptr 

Zeigt bei erfolgreicher Installation eines AHDI-kompatiblen Festplattentreibers auf die fol¬ 
gende Datenstruktur. Näheres dazu im Abschnitt “Treiber für Festplatten”. 


typedef struct 

{ 

WORD puns; 

BYTE pun[16]; 

LONG part_start[16]; 

LONG P_cookie; 

LONG *P_cookptr; 

UWORD P_version; 

DWORD Pjmax_sector; 

LONG re se rved[16]; 

) PUN INFO; 


/* Anzahl der Geräte */ 

/* diverse Flags */ 

/* Partitionsanfänge */ 

/* muß "AHM" sein */ 

/* zeigt auf das vorherige 
Element */ 

/* 0x0300 oder größer */ 

/* maximale Sektorgroße */ 


LONG $51A 1306 memval3 (ab TOS 1.02) 

Siehe auch memval und memval2. In diesem Fall ist der “magic value” $5555AAAA. 


LONG $51E 1310 xconstat (ab TOS 1.02) 

Acht Vektoren für “Bconstat()”-Routinen (mehr dazu in der BIOS-Einführung unter 
“Zeichenorientierte Funktionen”). 


LONG $53E 1342 xconin (ab TOS 1.02) 

Acht Vektoren für “Bconin()”-Routinen (mehr dazu in der BIOS-Einführung unter 
“Zeichenorientierte Funktionen”). 
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LONG $55E 1374 xcostat (ab TOS 1.02) 

Acht Vektoren für “Bcostat()”-Routinen (mehr dazu in der BIOS-Einführung unter “Zeichen¬ 
orientierte Funktionen”), Vorsicht : für “BcostatO” sind die Kanalnummern 3 (MIDI) und 4 
(IKBD) vertauscht, 

LONG $57E 1406 xconout (ab TOS 1.02) 

Acht Vektoren für “Bconout()”-Routinen (mehr dazu in der BIOS-Einführung unter “Zei- 
chen-orientierte Funktionen”). 

WORD $59E 1438 Jongframe 

Wenn dieses Flag nicht 0 ist, dann ist eine CPU mit langen Stackframes (also kein 68000er) 
installiert. 

Dieser Wert ist speziell dann von Interesse, wenn man eine Routine in einen Exception-Vektor 
einklinken will und die zu untersuchenden Werte auf dem Stack übergeben werden. Wenn 
“Jongframe” 0 ist, findet man dann die Parameter bei Offset 6, ansonsten bei Offset 8. 

Man kann sich übrigens durchaus darauf verlassen, daß der hier stehende Wert korrekt ist. 
Hersteller von “Beschleunigerkarten” müssen sich sowieso darum kümmern, daß diese 
Systemvariable korrekt gesetzt ist - sonst würde ein großer Teil der Atari-Systemsoftware 
(wie zum Beispiel der Diablo-Emulator der SLM-Laserdrucker) nicht funktionieren. 

LONG $5A0 1440 ji cookies 

Zeiger auf den Cookie Jar (deutsche Übersetzung: “Keksdose”). Dokumentation im Anschluß 
zu diesem Abschnitt. 

LONG $5A4 1444 ramtop 

Zeiger auf das Ende des Fast-RAMs im TT. Nicht offiziell dokumentiert! 

LONG $5A8 1448 ramvalid 

Magic-Wert, der anzeigt, ob “ramtop” einen sinnvollen Wert enthält (muß $ 1357BD13 sein). 
Nicht offiziell dokumentiert! 

LONG $5AC 1452 bell_hook (ab TOS 1.06) 

Zeiger auf Routine zur Ausgabe des “Ping”-Geräusches. 
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BIOS sorgt selbsttätig für die Abfrage des Flags in “conjerm” und ruft diese Routine nur dann 
auf, wenn das Geräusch wirklich erklingen soll. Die Routine wird im Supervisor-Modus 
aufgerufen, per “rts” abgeschlossen und darf die Register D0-D2 und A0-A2 verändern. Auch 
BIOS-Aufrufe vom “Innern” der Routine aus sind erlaubt. 

LONG $5B0 1456 kcl_hook (ab TOS 1.06) 

Zeiger auf Routine zur Ausgabe des Tastenkück-Geräuschs. BIOS sorgt selbsttätig für die 
Abfrage des Flags in “conjerm” und ruft diese Routine nur dann auf, wenn das Geräusch 
wirklich erklingen soll. Die Routine wird im Supervisor-Modus aufgerufen, per “rts” 
abgeschlossen, darf die Register D0-D2 und A0-A2 verändern und sollte nicht allzu viel Zeit 
verbrauchen. 


Der Cookie Jar 

Einleitung 

Beim “Cookie Jar” (“Keksdose”) handelt es sich im Grunde genommen um eine Generalisierung 
der Systemvariablen. Die wichtigsten Unterschiede; 

- Der Cookie Jar ist eine Tabelle, von der nur die Basisadresse bekannt ist. Damit kann sie 

bei Bedarf verlängert und im Speicher umhergeschoben werden. 

Jeder Eintrag im Cookie Jar hat eine (hoffentlich) eindeutige Kennung. Damit hat man 
die Möglichkeit, auch selbst Einträge für eigene Zwecke vorzunehmen. 

“Cookie” ist ein im Atari-Slang gebräuchlicher Terminus und steht für meist 32 Bits große 
Codenummern. Meistens interpretiert man sie als vier ASCII-Zeichen, die eine Abkürzung 
über den jeweiligen Verwendungszweck enthalten. Zu jedem Cookie gehört ein 32 Bits großer 
Eintrag, der je nach Cookie verschiedene Bedeutungen haben kann. Meist handelt es sich um 
Zeiger auf weitere Strukturen oder um Versionsnummem. Der “Cookie Jar” ist nichts anderes 
als ein Array von Cookies und ihren Werten. 


Einige Anwendungsbeispiele 

“MACCEL3”, der Mausbeschleuniger von Atari (gehört zum Lieferumfang von Mega STE 
und TT), trägt in den Cookie Jar einen Zeiger auf eine programminteme Struktur ein, mit deren 
Hilfe man im laufenden Betrieb seine Parameter verstellen kann (MACCEL3 benutzt aller- 
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dings einen Cookie, der nicht aus ASCII-Zeichen besteht- wohl deshalb, weil sein Vorgänger 
MACCEL2 vor der eigentlichen Definition des Cookie Jar entstanden ist). In diesem Fall wird 
der Cookie also von einem residenten Utility installiert, das über den Cookie Datenstrukturen 
zur Konfiguration nach “außen” führt. Diese Schnittstelle kann dann von einem Accessory 
oder einem Kontrollfeld-Modul genutzt werden. 

Das BIOS trägt ab TOS 1.06 die sogenannten System-Cookies ein, mit Hilfe derer man detail¬ 
lierte Informationen über die installierte Hardware erfragen kann. 


Aufbau des Cookie Jar 

Der Zeiger bei Adresse $5A0 (“_p_cookies”) ist entweder 0 (dann ist noch kein Cookie Jar 
installiert), oder er zeigt auf eine Tabelle von Paaren von 32-Bit-Werten. 

Im ersten steht jeweils die Identifikation in Form von vier ASCII-Zeichen. Bei der Definition 
eigener Kennungen sollte man folgendes beachten: 

- Mit beginnende Kennungen sind für Atari reserviert. 

- Die vier Buchstaben sollten im engsten Sinne “druckbar” sein (ASCII-Codes zwischen 
32 und 126, keine nationalen Sonderzeichen!). 

- Die vier Buchstaben sollten eine Abkürzung ergeben, aus der man auf das zugehörige 
Programm schließen kann. Varianten der Wörter “Cookie”, “Vector” u. ä. gehören nicht 
dazu! 

Das Ende der Liste wird durch einen “Nullcookie” angezeigt (also $00000000), der als Wert 
die maximale Anzahl von Einträgen im Cookie Jar enthält. 


Abfrage von Cookies 

Es ist leicht, Werte existierender Cookies abzufragen - eine Beispielfunktion in ANSI-C: 

/* WORD GetCookie (LONG cookie, LONG *value) 

"cookie" im Cookie Jar suchen. 

Bei Erfolg wird der Wert in "value" abgelegt und als 
Funktionswert TRUE zurückgeliefert. Anderenfalls erhält 
man FALSE. */ 
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WORD GetCookie (LONG cookie, LONG *value) 

{ 

LONG oldstack; 

LONG *cookiejar; 

/* Zeiger auf Cookiejar holen */ 

oldstack = Super (OL); 
cookiejar = *((LONG **)0x5a0L); 

Super ((void *) oldstack); 

/* Cookiejar überhaupt vorhanden? */ 
if (cookiejar = OL) 
return FALSE; 
do 
{ 

/* Cookie gefunden? */ 
if (cookiejar[0] ~ cookie) 

{ 

/* nur eintragen, wenn "value" kein Nullpointer */ 
if (value) 

*value = cookiejar[1]; 
return TRUE; 

} 

eise 

{ 

/* nächsten Cookie nehmen */ 
cookiejar = & (cookiejar[2]); 

} 

} while (cookiejar[-2]); /* Nullcookie? */ 
return FALSE; 

} 


Installation eigener Cookies 

Wie trägt man nun “seinen” Cookie in die Liste ein? Dazu stellt man zunächst fest, wie lang 
die Liste eigentlich ist (also vom Beginn der Liste an nach dem “Nullcookie” suchen, dessen 
Wert ja die Länge der Liste anzeigt). Da eben dieser Nullcookie auch das Ende der Liste 
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anzeigt, muß man nur dort seinen eigenen Cookie hineinkopieren und den Nullcookie um 
einen Eintrag zum Ende hin zu verschieben. 

War die Liste allerdings schon voll, dann bleibt nichts anderes übrig, als Platz für eine neue 
(längere) Liste zu allozieren, die alten Einträge dorthin zu kopieren und “_p_cookies” 
umzubiegen. Wenn man schon dabei ist, sollte man vielleicht gleich mehr Platz als für einen 
zusätzlichen Cookie schaffen. 

Dies geht logischerweise nur in Programmen, die sich nach ihrem Aufruf mittels “Ptermres()” 
resident im Speicher verankern. Andere Programme oder Acessories können und dürfen keine 
Cookies installieren! Statt dessen sollte das AES-Message-Passing oder die Environment- 
Variablen benutzt werden. 

Bleibt noch die Frage: wie kann man einen Cookie wieder entfernen? Leider reicht es nicht, 
einfach den bestehenden Eintrag zu “löschen” (denn was soll schon ein “leerer” Eintrag sein?). 
Also kommt man nicht umhin, alle folgenden Cookies innerhalb des Cookie Jar um einen 
Eintrag nach vorne zu kopieren. 

Das ist zwar nicht sonderlich bequem, aber so oft wird man Cookies ja nicht entfernen... 


Der Cookie Jar vor TOS 1.06 

Vor TOS 1.06 wurde der Cookie Jar noch nicht automatisch installiert. Dann hat “_p_cookies” 
den Wert 0. 

Programme können allerdings problemlos einen leeren Cookie Jar anlegen und “_p_cookies” 
entsprechend setzen. Das System (und alle anschließend geladenen Programme) verhalten 
sich dann genauso, als wäre der Cookie Jar schon immer dagewesen. 

Nur eine Einschränkung ist zu berücksichtigen: bei einem Reset wird “_p_cookies” nicht 
automatisch gelöscht. Ein Programm, das einen neuen Cookie Jar anlegt, muß sich also auch 
darum kümmern, daß “_p_cookies” bei einem Reset wieder gelöscht wird! 

Dazu ein Beispielprogramm, das einen leeren Cookie Jar anlegt: 

; cookiejr.s ; 

; Assembler: MAS68 

; Installiert einen 40 Einträge langen 
; Cookie Jar, sofern noch nicht vorhanden 
; beseitigt ihn ggfs, bei einem Reset 
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RESMAGIC 

equ 

$31415926 

_resvalid 

equ 

$426 

resvector 

equ 

$42a 

_j?_cookies 

equ 

$5a0 


.text 


pea Install 

raove.w #38,-(sp) ; Supexec 

trap #14 ; XBIOS 

addq.l #6,sp 


tst.w dO ; installiert? 

beq Notlnstalled 


; Installationsmeldung ausgeben 


pea 

Success 



move.w 

#9, -(sp) 

r 

Cconws 

trap 

#1 

r 

GEMDOS 

; und resident halten 



move.1 

4 (sp), aO 

r 

Basepage 

move.1 

#$100,dO 

t 

256 Bytes Basepage 

add.l 

$C(aO),d0 

f 

p lten 

add.l 

$14(aO),d0 

} 

p_dlen 

add.l 

$lC(aO) ,d0 

r 

p bien 

clr .w 

- (sp) 



move.1 

dO,-(sp) 



move.w ' 

#49,-(sp) 

r 

Ptermres 

trap 

#1 

/ 

GEMDOS 

nstalled: 




pea 

Failure 



move.w 

#9, -(sp) 

/ 

Cconws 

trap 

#1 

t 

GEMDOS 

clr. w 

-(sp) 

r 

richtig terminieren 

trap 

#1 

r 

GEMDOS Pterm 

all: 




clr .w 

dO 
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tst.l 

_p__cookies ; schon installiert? 

beq 

Installlt 

rts 

; Schluß! 

Installlt: 

moveq 

#l,d0 

move. 1 

#NewCookies,_p cookies 

move. 1 

resvalid,OldValid 

move.1 

#RESMAGIC, __resvalid 

move. 1 

resvector,OldReset 

move.1 

rts 

#NewReset, resvector 


dc.b 
OldReset: 

dc.l 
NewReset: 
clr.l 
move.1 
move. 1 
jmp 

.data 

Success: 

.dc.b "cookiejr: Cookiejar for 40 cookies 

installed.",13,10,0 

Failure: 

.dc.b "cookiejr: Cookiejar already in use.",13,10,0 
NewCookies: 

.dc.l 0,40 ; 40 Stück 

.dcb.l 78,0 ; 78 mal 0 

.bss 

OldValid: 

.ds.l 1 


"XBRACKJR" ; XBRA-Struktur 

0 

_p_cookies ; wieder löschen 

OldReset,_resvector 
OldValid,_resvalid 
(a6) 


.end 



78 


ATARI Profibuch 


Vom BIOS belegte Cookies 

Ab TOS 1.06 wird der Cookie Jar automatisch bei der Systeminitialisierung installiert und mit 

einigen Informationen über den benutzen Rechner versehen. 

Zur Zeit sind folgende Cookies dokumentiert: 

CPU - Prozessortyp 

Hat die Werte 0,10,20,30 oder 40 für Rechner mit 68000,68010,68020,68030 oder 68040. 

FPU - FPU-Typ 

Dieser Cookie beschreibt, auf welche Art Hardware und Betriebssystem die Arbeit mit 

Fließkommazahlen unterstützen. Dabei sind verschiedene Schnittstellen denkbar: 

- In ST- und STE-Modellen kann der 68881 als Peripheriebaustein installiert werden 
(beim ST und STE über eine Steckkarte wie die SFP 004 von Atari; beim Mega STE über 
einen Steckplatz auf der Hauptplatine). 

- Bei Systemen mit 68020 oder 68030 kann eine eventuell vorhandene FPU über die Line- 
F-Instruktionen angesprochen werden. 

- Beim 68040 sind die meisten Befehle des 68882 direkt in der CPU eingebaut. Einige 
wenige Ausnahmen werden per Software emuliert. Beim Zugriff über Line-F besteht 
vollständige Kompatibilität. 

- Bei Rechnern mit TOS 1.06 oder neueren TOS-Versionen ist es denkbar, nachträglich 
einen Line-F-Treiber (für Softwareemulation oder für den Zugriff auf einen als 
Peripheriebaustein betriebenen 68881) zu betreiben. 

Das obere Wort beschreibt den Typ des benutzten Floating-Point-Koprozessors: 

Bit 0: falls gesetzt: SFP 004 oder kompatible FPU-Karte (68881 als Peripheriebau¬ 

stein) 

Bit 1..2: 68881 oder 68882 als Koprozessor, im Detail: 

0: weder - noch 

1: 68881 oder 68882, Typ unbekannt 
2: 68881 
3: 68882 

falls gesetzt: 68040 


Bit 3: 
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68881 und 68882 sind von der Softwareseite her praktisch vollständig kompatibel. Daher 
macht sich das BIOS des TT auch keine Mühe, den genauen Typ zu erkennen. Software, die 
die genaue Typenbezeichnung braucht, kann diese Information selbst zu ermitteln versuchen 
und den Cookie entsprechend korrigieren. 

Das untere Wort ist für Informationen über Softwareunterstützung via Line-F-Trap reserviert 
und ist zur Zeit noch nicht benutzt. Laut Atari bedeutet ein Wert ungleich 0, daß Line-F-Unter- 
stützung vorhanden ist. 

Für den Anwendungsprogrammierer sind eigentlich nur zwei Fragen interessant: 

1. Hat der Rechner eine als Peripheriebaustein installierte FPU? Hierfür sollte man bei 
vorhandenem FPU-Cookie Bit 0 des oberen Werts testen. Ist der Cookie nicht vorhanden 
(zum Beispiel in Versionen vor TOS 1.06), muß man direkt die Hardwareadressen über¬ 
prüfen (Löschen des LONG-Werts an Adresse $FFFFFA46 führt zum Bus-Error). 

2. Können die Line-F-Instruktionen für Floating-Point-Berechnungen benutzt werden? 
Hierzu reicht es, den FPU-Cookie zu testen. Wenn das obere Wort einen Wert größer 1 
oder das untere Wort einen Wert ungleich 0 hat, sind Line-F-Instruktionen erlaubt. 


JFRB - Fast-RAM-Buffer 

Da das “Fast RAM” des TT für normale ACSI-DMA-Transfers nicht benutzt werden kann, 
legt das BIOS auf solchen Rechnern einen 64 KByte großen Puffer im ST-RAM an, dessen 
Adresse man hier vorfindet. Gerätetreiber für die ACSI-Schnittstelle dürfen diesen Puffer als 
temporären Zwischenspeicher für Transfers in das Fast-RAM nutzen. Der Zugriff wird über 
die Systemvariable “flock” koordiniert. 

Wenn dieser Cookie nicht da ist, verfügt die Maschine entweder über kein Fast-RAM oder 
keine ACSI-Schnittstelle. 

_MCH - Maschinentyp 

Beschreibt den benutzten Rechnertyp. Das obere Wort bezeichnet die Rechnerfamilie: 

0: ST (520ST, 1040ST und Mega ST und ähnliche) 

1: STE (1040 STE, Mega STE) 

2: TT 


Das untere Wort dient für feinere Unterscheidungen und ist zur Zeit nur beim Mega STE 
(0x0010) ungleich 0. 
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_SND - Soundhardware 

Bittabelle, die die vorhandenen Soundmöglichkeiten beschreibt. 

Bit 0: Gl/Yamaha Sound Chip wie in bisher allen bekannten Rechnern 
Bit 1: Stereo-DMA-Sound (wie beim STE und dem TT) 

_SWI - DIP-Switches 

Werte der “Konfigurationsschalter” (Dip-Schalter), falls vorhanden. 

_VDO - Videohardware 

Beschreibt die verfügbare Videohardware. Das obere Wort wird für die grobe Klassifizierung 
benutzt. Das untere Wort ist für feinere Unterscheidungen reserviert. 

0: ST 
1: STE 
2: TT 


Weitere von Atari benutzte Cookies 


Neuere Systemsoftware bzw. Patchprogramme benutzen ebenfalls den Cookie Jar: 


Cookie Programm 

_FDC Dieser Cookie kann von Treibersoftware für Floppycontroller höherer 

Schreibdichte installiert werden. Das oberste Byte gibt über die Art der 
höchsten Schreibdichte im System Auskunft: 


Wert 


Bedeutung 


0 normales Floppyinterface (zum Beispiel 720K bei doppelseitigen Dis¬ 
ketten) 

1 “High-Density” (HD, 1,44 MByte bei 3,5-Zoll-Disketten) 

2 “Extra High Density” (ED, 2,88 MByte) 


Damit ist natürlich noch nicht garantiert, daß tatsächlich ein solches Laufwerk 
angeschlossen und eine passende Diskette eingelegt ist! 


Alle weiteren Werte sind für künftige Erweiterungen reserviert. Die restlichen 
drei Bytes beschreiben den Ursprung der Controller-Hardware: 
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Wert 

Bedeutung 

$000000 

keine Information verfügbar 

$415443 

(“ATC”) Die Hardware ist entweder Teil des Systems oder ist 
nachträglich auf solche Art und Weise in das System integriert 
worden, daß sie sich genauso wie ein Teil der Originalhardware 
einer Atari-Maschine verhält. 

$445031 

(“DPI”) Die Hardware entstammt einem Bausatz der Firma 
“DreamPark Development”. 

Alle anderen mit “DP” beginnenden Kennungen sind ebenfalls 
für diesen Hersteller reserviert. 

andere 

Hardwareentwickler können sich vom Atari-Entwickler-Support 
eigene Kennungen zuteilen lassen. 


_FLK Wenn dieser Cookie existiert, dann verfügt das installierte Gemdos über File- 

Locking-Erweitcrungen (Wert des Cookies ist die Versionsnummer der Erwei¬ 
terung). 

_INF STEFIX. Patchprogramm für Fehler im Desktop von TOS 1.06. 

_NET Flag für GEMDOS-Netzwerkerweiterungen. Der Inhalt des Cookies ist ein 

Zeiger auf zwei LONG-Werte. Der erste enthält eine Herstellerkennung für das 
Netzwerk, der zweite die vom Hersteller vergebene Versionsnummer. 

_OOL POOLFIX3. Patchprogramm für Fehler in GEMDOS-Version 0.15. 

__SLM Diablo-Treiber für SLM-Laserdrucker (Wert zeigt auf nicht dokumentierte 

Struktur). 

Außerdem benutzt auch der Maus-Beschleuniger “MACCEL3” den Cookie Jar. 

Der Cookie selbst besteht jedoch nicht aus druckbaren ASCII-Zeichen. 


Das XBRA-Verfahren für vektorverbiegende 
Programme 

Speicherresidente Programme, die Vektoren verbiegen, haben stets zwei Probleme: 

- Sie können den Vektor nur schwer zurücksetzen, da sich ja unter Umständen mittlerweile 
ein anderes Programm in den gleichen Vektor gehängt haben könnte. 

- Sie können aus dem gleichen Grund nur schwer überprüfen, ob sie bereits installiert sind. 
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Das hier angegebene XBRA-Verfahren (“eXtended BRAner”) wurde erstmals 1988 im “Atari 
ST Profibuch” vorgeschlagen und geht auf eine Idee von Moshe Braner zurück, die nur in 
einem Punkt etwas erweitert wurde. Jedes vektorverbiegende Programm plaziert direkt vor 
seiner eigenen Einsprungadresse (also genau vor der Adresse, auf die der Vektor gesetzt 
wurde) folgende Struktur: 

typedef struct 

{ 

char xbjnagic[4); 
char xb_id[4]; 

LONG xb_oldvec; 

} XBRA; 

Die Konstante “xb_magic” wurde hinzugefügt, um eine hundertprozentige Erkennung der 
XBRA-Struktur zu ermöglichen. Mit diesen zusätzlichen Informationen können Programme 
leicht feststellen, ob sie schon installiert sind, und sich leicht aus der Vektorkette ausklinken. 

Ohne Übertreibung kann man sagen, daß sich das XBRA-Verfahren vollständig durchgesetzt 
hat. Mittlerweile wird es gemeinhin als schlechter Programmierstil angesehen, wenn man es 
nicht benutzt. Selbst Atari Amerika verbiegt in eigenen Utilities und Patchprogrammen die 
Vektoren mittlerweile XBRA-kompatibel. 

Es ist erstrebenswert, daß es nicht zu Doppeltbelegungen von XBRA-Kennungen kommt. 
Daher führt der Autor die sogenannte “XBRA-Liste”, in der offiziell gemeldete Kennungen 
eingetragen werden und die in regelmäßigen Abständen in Fachzeitschriften veröffentlicht 
wird. Anfragen bitte (vollständig mit Autor und Bezugsquelle für das betreffende Programm 
und einer Aufstellung der benutzten Systemadressen) an: 

Julian Reschke 
Redaktion ST-Magazin 
Markt & Technik Verlag AG 
Hans-Pinsel-Straße 2 


/* "XBRA" = 0x58425241 */ 

/* vier Buchstaben lange Kennung wie beim 
Cookie Jar */ 

/* ursprünglicher Wert des Vektors */ 


8013 Haar bei München 
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BIOS-Referenz 


Bconin (BIOS 2) 

Liest ein Zeichen von einem Eingabegerät ein, sobald es verfügbar ist. Daher sollte man diese 
Funktion nach Möglichkeit zusammen mit “Bconstat()” verwenden! 

Deklaration in C: 

IiONG Bconin (WORD dev) ; 

Aufruf in Assembler: 

move.w dev,-(sp) ; Offset 2 

move.w #2,-(sp) ; Offset 0 

trap #13 

addq.l #4,sp 

Parameter: 

dev: Nummer des betreffenden Eingabegeräts: 

PRT (0): parallele Schnittstelle 

AUX (1): serielle Schnittstelle 

CON (2): Konsole (VT-52) 

MIDI (3): MIDI 

Bconin(): Bits 0..7: das eingelesene Zeichen 

Bemerkungen 

Für das Gerät “CON” enthalten die Bits 16..23 den Scancode der betreffenden Taste. Ist 
zusätzlich das entsprechende Bit in der Systemvariable conterm gesetzt, dann findet man in 
den Bits 24-31 den aktuellen Wert von “KbshiftQ”. 
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Bconout (BIOS 3) 

Gibt ein Zeichen auf dem angegebenem Gerät aus (und kehrt erst dann zurück, wenn das 
Zeichen tatsächlich ausgegeben worden ist - also Vorsicht bei Benutzung des Druckers u.ä.). 

Deklaration in C: 

void Bconout (WORD dev, WORD c); 


Aufruf in Assembler: 

move.w c,-<sp) ; Offset 4 

move.w dev,-(sp) ; Offset 2 

move.w #3,-(sp) ; Offset 0 

trap #13 

addq.l #6,sp 

Parameter: 

dev: Nummer des betreffenden Ausgabegeräts: 

PRT (0): parallele Schnittstelle 

AUX (1): serielle Schnittstelle 

CON (2): Konsole (VT-52) 

MIDI (3): MIDI-Schnittstelle 

IKBD (4): Tastatur-Prozessor 

RAWCON (5): Konsole (ohne Terminalemulation) 

c: Auszugebendes Zeichen 

Bemerkungen 

Man beachte, daß aufgrund eines Fehlers die mit “SetprtO” gemachten Einstellungen ignoriert 
werden. 

Die Zeichenausgabe über “RAWCON” ist übrigens ein ganzes Stück schneller als die über 
“CON”, da die VT52-Sequenzen nicht ausgewertet werden müssen. 

Für den Drucker wird im Fehlerfall 0 zurückgeliefert. 
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Bconstat (BIOS 1) 

Stellt den Status eines Eingabegerätes fest. 

Deklaration in C: 

WORD Bconstat (WORD dev); 

Aufruf in Assembler: 

move.w dev r -(sp) ; Offset 2 

move.w #l,-(sp) ; Offset 0 

trap #13 

addq.l #4,sp 

Parameter: 

dev: Nummer des betreffenden Eingabegeräts: 

AUX (1): serielle Schnittstelle 

CON (2): Konsole (VT-52) 

MIDI (3): MIDI-Port 

Bconstat(): 0: kein Zeichen verfügbar 

-1: mindestens ein Zeichen kann eingelesen werden 

Bemerkungen 

Die Geräte “AUX” und “MIDI” werden per Interrupt betrieben, mehr dazu unter “Iorec()”, 
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Bcostat (BIOS 8) 


Liefert den Ausgabestatus eines Ausgabegeräts. 

Deklaration in C: 

LONG Bcostat (WORD dev); 


Aufruf in Assembler: 

move.w dev,-(sp) ; Offset 2 

move.w #8,-(sp) ; Offset 0 

trap #13 

addq.l #4,sp 


Parameter: 

dev: 


BcostatQ: 


Nummer des betreffenden Ausgabegeräts: 

PRT (0): parallele Schnittstelle 

AUX (1): serielle Schnittstelle 

CON (2): Konsole (VT-52) 

IKBD (3): Tastatur-Prozessor 

MIDI (4): MIDI-Schnittstelle 

RAWCON (5): Konsole (ohne Terminalemulation) 

0: Zeichen kann noch nicht gesendet werden 

—1: Zeichen kann gesendet werden 


Bemerkungen 

Man beachte die Vertauschung von “MIDI” und “IKBD” gegenüber den anderen BIOS- 
Funktionen! Laut Atari wird dies aus Kompatibilitätsgründen auch so bleiben. 
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Drvmap (BIOS 10) 


Liefert einen Bitvektor der dem BIOS bekannten logischen Laufwerke. 


Deklaration in C: 

LONG Drvmap (void); 


Aufruf in Assembler: 

move.w #$A,-(sp) ; Offset 0 

trap #13 

addq.l #2,sp 


Parameter: 

Drvmap(): Bitvektor mit den vorhandenen Laufwerken (A: Bit 0, B: Bit 1...). 

Es sind also 32 Geräte möglich! 

Bemerkungen 

“DrvmapO” liefert den Inhalt der Systemvariable “_drvbits” zurück. 

Normalerweise ist es interessanter, welche Laufwerke GEMDOS kennt. Um das festzustellen, 
sollte man besser die GEMDOS-Funktion “DsetdrvQ” einsetzen. 
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Getbpb (BIOS 7) 


Liefert Adressen auf den BIOS-Parameter-Block des betreffenden Geräts (springt dazu durch 
den Vektor “hdv_bpb” ($472)): 


typedef struct 
{ 

WORD recsiz; 
WORD clsiz; 
WORD clsizb; 
WORD rdlen; 
WORD fsiz; 
WORD fatrec; 
WORD datrec; 
WORD numcl; 
WORD bflags; 


) BPB; 


/* Bytes pro Sektor */ 

/* Sektoren pro Cluster (Einheit) */ 

/* Bytes pro Cluster */ 

/* Länge des Wurzelverzeichnis in Sektoren */ 
/* Länge des File Allocation Table (FAT) */ 

/* Startsektor der zweiten FAT */ 

/* Sektomummer des ersten freien Clusters */ 
/* Gesamtzahl der Cluster auf dem Medium */ 

/* Bitvektor, zur Zeit nur Bit 0 belegt: 

0 (12-Bit-FAT), 1 (16-Bit-FAT) */ 


Deklaration in C: 

BPB *Getbpb (WORD dev); 


Aufruf in Assembler: 

move.w dev,-(sp) ; Offset 2 

move.w #7,-(sp) ; Offset 0 

trap #13 

addq.l #4,sp 

Parameter: 

dev: Gerätenummer (A: 0, B: 1, C: 2...) 

Getbpb(): Zeiger auf den BPB des Geräts oder im Fehlerfall 0 (zum Beispiel, wenn die 

Informationen im Bootsektor den Verdacht nahelegen, daß die Diskette nicht 
korrekt formatiert ist) 

Bemerkungen 

“GetbpbO” setzt den Mediachange-Status im BIOS zurück. Weitere Hinweise dazu finden Sie 
in der Einführung zum GEMDOS. 
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Getmpb (BIOS 0) 


Diese Funktion dient zur Initialisierung der Speicherverwaltung. Sie wird von GEMDOS ein 
einziges Mal beim Starten des Systems aufgerufen, um die Ursprungs-TPA zu erzeugen (mehr 
dazu in der GEMDOS-Einführung), und darf anschließend nicht noch einmal aufgerufen wer¬ 
den. 

“GetmpbO” füllt eine Speicherparameter-Struktur (Memory Parameter Block), die folgende 
Gestalt hat: 

typedef struct 
{ 

MD *mp__mfl; /* Zeiger auf "Memory Free List" */ 

MD *mp_mal; /* Zeiger auf "Memory Allocated List" */ 

MD *mp_rover; /* roving pointer; wird nur intern benötigt */ 

}MPB; 

Die MD-Struktur hat das folgende Format: 

typedef struct md 
{ 

struct md *m_link; /* Zeiger auf nächsten MD */ 

LONG m_start; /* Anfangsadresse des Blocks */ 

LONG m_length; /* Länge des Blocks */ 

BASEPAGE *m_own; /* Zeiger auf Prozeß-Beschreibungsstruktur 

*/ 

} MD; 

Jede MD enthält also einen Zeiger auf eine weitere Struktur (verkettete Liste) sowie die 
Anfangsadresse und die Länge des entsprechenden Speicherabschnitts. 

“m_own” zeigt auf die BASEPAGE-Struktur des Prozesses, dem der Speicherblock gehört. 


Deklaration in C: 

void Getmpb (MPB *p_mpb); 
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Aufruf in Assembler: 

pea p_mpb 

move.w #G,-(sp) 

trap #13 

addq.l #6,sp 

Parameter: 

p_mpb: zeigt auf eine vom Programm zur Verfügung gestellte MPB-Struktur 


; Offset 2 
; Offset 0 
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Kbshift (BIOS 11) 


Liefert oder verändert den momentanen Tastaturstatus. Die Bitbelegung sieht folgenderma¬ 
ßen aus: 


Bit 


Belegung 


BitO 
Bit 1 
Bit 2 
Bit 3 
Bit 4 
Bit 5 
Bit 6 
Bit 7 


Shift-Taste rechts 
Shift-Taste links 
Control-Taste 
Altemate-Taste 
CapsLock gesetzt 
Maustaste rechts (ClrHome) 
Maustaste links (Insert) 
reserviert (0) 


Deklaration in C: 

LONG Kbshift {WORD mode); 


Aufruf in Assembler: 

move.w mode,-(sp) 
move.w #$B,-(sp) 

trap #13 

addq.l #4,sp 


; Offset 2 
; Offset 0 


Parameter: 

mode: entweder negativ (dann wird nur der aktuelle Status zurückgeliefert) oder >=0 

(dann legt mode den neuen Status fest) 

Kbshift(): aktueller (bzw. bisheriger) Tastaturstatus 

Bemerkungen 

“KbshiftO” fragt lediglich eine BlOS-inteme Systemvariable ab. Deren Adresse kann man bei 
Bedarf (also zum Beispiel in Interrupt-Routinen) mit Hilfe von “_sysbase” berechnen. 
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Mediach (BIOS 9) 

Stellt fest, ob ein Medienwechsel stattgefunden hat. Für Disketten sind folgende Hinweise zu 
beachten: die Erkennung eines Diskettenwechsels funktioniert nur dann korrekt, wenn die 
Diskette nicht schreibgeschützt ist. Im Zweifelsfall ist es wichtig, daß Disketten unterschied¬ 
liche Seriennummem tragen, was nicht bei allen Formatierprogrammen und auch nicht bei 
unter MS-DOS formatierten Disketten gewährleistet ist. 

Doch nicht nur Disketten können gewechselt werden: auch bei Wechselplatten oder CD- 
ROMs (oder anderen “neuartigen” Geräten) kann es zu einem Medienwechsel kommen. 

Daher: Niemals davon ausgehen, daß ein Gerät nicht wechselbar ist! 

Deklaration in C: 

LONG Mediach (WORD dev); 

Aufruf in Assembler: 

move.w dev,-(sp) ; Offset 2 

move.w #9,-(sp) ; Offset 0 

trap #13 

addq.l #4,sp 

Parameter: 

dev: Nummer des Laufwerks (A: 0, B: 1, C: 2...) 

Mediach(): 0: Medium wurde mit Sicherheit nicht gewechselt 

1: Medium wurde möglicherweise gewechselt 

2: Medium wurde mit Sicherheit gewechselt 

(endlich einmal dreiwertige Logik!) 

Bemerkungen 

Normalerweise wird diese Funktion vom GEMDOS aufgerufen. Dabei sind folgende Fälle 
möglich: 

Retum-Wert 0: Alles ist in Ordnung, und GEMDOS arbeitet normal weiter. 

Return-Wert 1: GEMDOS macht einen Lesezugriff, um einen definitiven Status zu 

erfragen. 
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Return-Wert 2: 


GEMDOS erkennt den Medienwechsel, vergißt alle Informationen über 
das Laufwerk (siehe in der GEMDOS-Einführung zum Thema 
“Medienwechsel”) und ruft “GetbpbO” auf. Dadurch wird dem BIOS 
signalisiert, daß der Medienwechsel verarbeitet ist und der Status 
zurückgesetzt werden kann. 
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Rwabs (BIOS 4) 


Liest und schreibt logische Sektoren von Disketten oder anderen Geräten, die über die 
Harddisk-Vektoren (ab $46a, “hdv_init”) installiert sind. Dazu gehören natürlich nicht nur 
Festplatten, sondern auch RAM-Disks und Cache-Programme. Diese BIOS-Routine springt 
dazu direkt durch den Vektor “hdv_rw” ($476). 

Beim Betrieb von Festplatten kann man normalerweise nur auf die einzelnen Partitionen 
zugreifen. Um Festplatten partitionieren zu können, muß man allerdings direkten Zugriff auf 
alle Sektoren der Platte haben. 

AHDI-3.0-kompatible Festplattentreiber kennen daher eine Erweiterung, die den direkten 
(physikalischen) Zugriff aus die Festplatten zuläßt. 

Auch der Parameter “lrecno” ist eine Erweiterung, die es nur mit AHDI-3.0-kompatiblen 
Festplattentreibem gibt. Damit ist es möglich, auf mehr als 65535 Sektoren der Platte zuzu¬ 
greifen (was bei Festplatten mit mehr als 32 MByte Größe natürlich sehr wichtig ist). 

Wie stellt man fest, ob ein solcher Festplattentreiber installiert und für welche Geräte er 
zuständig ist? 

Ganz einfach: Man inspiziert die Systemvariable “pun_ptr”, die auf eine Struktur mit allen 
notwendigen Informationen zeigen sollte. 


Deklaration in C: 

LONG Rwabs (WORD rwflag, void *buf, WORD count, WORD recno, 



WORD dev. 

LONG 

lrecno); 


Aufruf in Assembler: 





move.1 

lrecno, - (sp) 

f 

Offset 

14 

41 

move.w 

dev, - (sp) 

} 

Offset 

12 

W 

move.w 

recno,-(sp) 

/ 

Offset 

10 

4l 

move.w 

count,-(sp) 

r 

Offset 

8 

JO 

pea 

buf 

/ 

Offset 

4 

b 

move.w 

rwflag,-(sp) 

r 

Offset 

2 

vdp 

move.w 

#4, -(sp) 

t 

Offset 

0 


trap 

#13 





lea 

$12(sp),sp 






tnl l/_ /V ' 
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Parameter: 


dev: Im Normalmodus: Nummer des logischen Laufwerks (A: 0, B: 1, C: 2,..). 

Im “physikalischen” Modus: 2 plus Gerätenummer (also 2..9 für ACSI-Platten, 
10..17 für SCSI-Platten). 

recno: Nummer des ersten Sektors (bei -1 wird statt dessen “lrecno” benutzt) 

lrecno: dieser Parameter wird nur benutzt, wenn “recno” -1 ist und man einen AHDI- 

3.0-kompatiblen Festplattentreiber benutzt (siehe unter “pun_ptr”) 
count: Anzahl der zu übertragenden Sektoren 

buf: Anfangsadresse des Puffers (darf auf ungerader Adresse liegen, was allerdings 

die Geschwindigkeit verringert!) 
rwflag: Bitvektor, der die Art der Operation festlegt; 

BitO: lesen (0) oder schreiben (1) 

Bit 1: Medienwechsel beachten (0) oder ignorieren (1) 

Bit 2: Im Fehlerfall “Retry” versuchen (0) oder nicht (1) (nur bei zu AHDI 3.0 
kompatiblen Festplattentreibem) 

Bit 3; Normalmodus (0) oder “physikalischer” Modus (1) (nur bei zu AHDI 
3.0 kompatiblen Festplattentreibem) 

Rwabs(): 0 (OK) oder eine BIOS-Fehlermeldung 
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Setzt und liest die Inhalte von Exception-Vektoren. 

Die Vektoren 2 bis 255 sind durch die Exceptions der CPU belegt. Ihre Vektoren liegen an 
den Adressen $8 bis einschließlich $3FF. 

Die acht weiteren Vektoren 256 bis 263 sind für GEMDOS reserviert und liegen zur Zeit an 
den Adressen $400 bis $41F. Das muß natürlich nicht unbedingt so bleiben. Mehr zu den 
GEMDOS-Vektoren finden Sie im entsprechenden Abschnitt der GEMDOS-Einführung. 

Deklaration in C: 

LONG Setexc (WORD veenum, void (*vec)()); 

Aufruf in Assembler: 

pea vec 

move.w veenum,-(sp) 
move.w #5,-(sp) 

trap #13 

addq.l #8,sp 

Parameter: 

veenum: Nummer des zu setzenden Exception-Vektors (ist identisch mit der zu setzen¬ 

den Adresse, dividiert durch 4) 

vec: Neue Adresse (oder -1, wenn diese nicht verändert werden soll) 

Setexc(): Bisheriger (bzw. aktueller) Wert des Vektors 


; Offset 4 
; Offset 2 
; Offset 0 
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Tickcai (BIOS 6) 

Liefert den Inhalt von also die Anzahl von Millisekunden zwischen zwei 

Aufrufen des Systemtimers, 

Deklaration in C: 

LONG Tickcai (void); 

Aufruf in Assembler: 

move.w #6,-(sp) ; Offset 0 

trap #13 

addq.l #2,sp 

Parameter: 

Tickcal(): Anzahl der Millisekunden 
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XBIOS-Referenz 


Bconmap (XBIOS 44) - nicht auf allen TOS-Versionen 


Mit dieser Funktion kann dem BIOS-Kanal 1 (serielle Schnittstelle) eine der erweiterten 
Kanalnummern zugeordnet werden. Die bisherzugeordneteKanalnummerwird zurückgeliefert. 

Als Sonderfall kann ein Zeiger auf die BCONMAP-Struktur abgeff agt werden, über die man 
die maximal erlaubte BIOS-Gerätenummer abfragen und neue Gerätetreiber installieren kann 
(siehe Einleitung zum XBIOS). 

“BconmapO” beeinflußt einerseits die BlOS-Vektortabelle in den Systemvariablen (begin¬ 
nend bei “xconstat”, Adresse $51E). Andererseits wird auch das Verhalten von “RsconfO” und 
“Iorec()” entsprechend modifiziert. 


Deklaration in C: 

LONG Bconmap (WORD devno); 


Aufruf in Assembler: 

move.w devno,-(sp) 

move.w #$2C,-(sp) 

trap #14 

addq.l #4,sp 


; Offset 2 
; Offset 0 


Parameter: 

devno: -2: Zeiger auf BCONMAP-Struktur zurückliefem 

—1: Nur aktuelle Kanalnummer abfragen 

0: Test, ob “BconmapO” vorhanden ist 

>=6: Neue Kanalnummer 

bei ungültigen Angaben (kleiner-3 oder zwischen 0 und 5) wird 0 zurückgeliefert 
BconmapO: für devno = -2: Zeiger auf BCONMAP-Struktur 

sonst: bisher eingestellte Kanalnummer 
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Bemerkungen 

Laut Atari-Systemprogrammierer Allan Pratt sollte man seine TOS-Version folgendermaßen 
auf das Vorhandensein von “BeonmapO” testen: 

WORD has_bconmap (void) 

{ 

return (OL = Bconmap (0)); 

} 
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Bioskeys (XBIOS 24) 

Stellt die ursprüngliche Tastaturbelegung (die man mit “KeytblO” ändern kann) wieder her. 

Deklaration in C: 

void Bioskeys (void) ; 

Aufruf in Assembler: 

move.w #$18,-(sp) ; Offset 0 

trap #14 

addq.l #2,sp 
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Blitmode (XBIOS 64)-erst ab TOS 1.02 

Diese Funktion dient zur Konfiguration des Blitter-Chips (ab TOS 1,02). 


Deklaration in C: 

WORD Blitmode (WORD mode); 


Aufruf in Assembler: 

move.w mode,-(sp) ; Offset 2 

move.w #$40,-(sp) ; Offset 0 

trap #14 

addq.l #4,sp 


Parameter: 

mode: -1: Status der Blitterregister auslesen 

sonst: Blitterbetrieb wird umgeschaltet. 

In Bit 0 wird folgende Information übergeben: 

0: Blitter aus (wird durch Bildschirmtreiber nicht benutzt) 

1: Blitter an (wird durch Bildschirmtreiber benutzt) 

Bit 15 muß 0 sein 
Blitmode(): Bisheriger Blitterstatus: 

Bit 0: Blitter wird nicht benutzt (0) 

Blitter wird benutzt (1) 

Bit 1: kein Blitter installiert (0) 

Blitter-Chip vorhanden 
Bit 15:0 

Alle weiteren Bits sind reserviert 
Bemerkungen 

Obwohl in TOS 1.00 nicht vorhanden, darf man laut Atari “BlitmodeO” ohne Versionsabfrage 
benutzen (ein Seiteneffekt im XBIOS-Dispatcher macht es möglich). Darauf sollte man sich 
aber besser nicht verlassen - vielleicht gibt es ja Programme, die den XBIOS-Trap “verbie¬ 
gen” und nicht darauf achten, daß für Opcode 64 der gleiche Return-Wert wie beim ROM 
zurückgeliefert wird. 
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Legt verschiedene Cursor-Attribute fest oder fragt die Blinkfrequenz des Cursors ab. 


Deklaration in C: 

WORD Cursconf (WORD function, WORD Operand); 


Aufruf in Assembler: 

move.w Operand,-(sp) ; Offset 4 

move.w function,-(sp) ; Offset 2 

move.w #$15,-(sp) ; Offset 0 

trap #14 

addq.l #6,sp 


Parameter: 

function: CURS_HIDE (0): Cursor ausschalten 

CURS_SHOW (1): Cursor einschalten 

CURS_BLINK (2): Cursorblinken einschalten 

CURS_NOBLINK (3): Cursorblinken ausschalten 

CURS_SETRATE (4): Blinkrate auf “Operand” stellen 

CURS_GETRATE (5): Blinkrate abfragen 

Operand: nur bei “CURS_SETR ATE” benutzt; gibt an, nach wie vielen Vertical Blanks 

der Cursor einmal invertiert wird 
CursconfO: bei “CURS_GETRATE” aktuelle Blinkrate 
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DMAread (XBIOS 42) - nicht auf allen TOS-Versionen 


Liest eine Anzahl von Sektoren von einem ACSI- oder SCSI-Gerät. Der zu übertragende 
Speicherbereich muß für die jeweilige Hardware beschreibbar sein (mehr dazu im Hardwareteil). 

In den allermeisten Fällen ist es sinnvoller, statt dessen die Funktion “Rwabs()” zu verwenden! 


Deklaration in C: 

LONG DMAread (LONG sector, WORD count, void *buffer, WORD devno); 


Aufruf in Assembler: 


move.w 
pea 

move.w 
move.1 
move.w 
trap 
lea 


devno,-(sp) 
buffer 
count,-(sp) 
sector,-(sp) 
#$2A,-(sp) 

#1 

$E (sp), sp 


; Offset 12 
; Offset 8 
; Offset 6 
; Offset 2 
; Offset 0 


Parameter: 

sector: erste Sektomummer 

count; Anzahl der Sektoren 

buffer: Anfangsadresse im Speicher 

devno: Gerätenummer (0..7: ACSI-Geräte 0..7, 8.. 15: SCSI-Geräte 0..7, darüber: 

reserviert für künftige Erweiterungen) 

DMAwrite(): liefert einen BIOS-Fehlercode zurück (0: OK) 


Bemerkungen 

Geräte am SCSI-Bus werden von dieser Funktion per Handshake (also nicht per DMA) 
betrieben. 
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DMAwrite (XBIÖS 43) - nicht auf allen TOS-Versionen 

Schreibt eine Anzahl von Sektoren auf ein ACSI- oder SCSI-Gerät. Der zu übertragende 
Speicherbereich muß für die jeweilige Hardware lesbar sein (mehr dazu im Hardwareteil). 

In den allermeisten Fällen ist es sinnvoller, statt dessen die Funktion “RwabsO” zu verwenden! 

Deklaration in C: 

LONG DMAwrite (LONG sector, WORD count, void *buffer, WORD devno); 


Aufruf in Assembler: 



move.w 

devno,-(sp) ; 

Offset 

12 

pea 

buffer ; 

Offset 

8 

move.w 

count,-(sp) ; 

Offset 

6 

move.1 

sector,-(sp) ; 

Offset 

2 

move.w 

#$2B, -(sp) 

Offset 

0 

trap 

#1 



lea 

$E(sp),sp 



Parameter: 




sector: 

erste Sektomummer 



count: 

Anzahl der Sektoren 




buffer: Anfangsadresse im Speicher 

devno: Gerätenummer (0..7: ACSI-Geräte 0..7, 8..15: SCSI-Geräte 0..7, darüber: 

reserviert für künftige Erweiterungen) 

DMAwrite(): liefert einen BIOS-Fehlercode zurück (0: OK) 


Bemerkungen 

Geräte am SCSl-Bus werden von dieser Funktion per Handshake (also nicht per DMA) 
betrieben. 
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Dosound (XBIOS 32) 


Mit dieser Funktion kann man vollautomatisch eine Reihe von Werten in die Register des 
Soundchips schreiben lassen. 

Deklaration in C: 

void Dosound (const char *ptr); 

Aufruf in Assembler: 

pea ptr ; Offset 2 

move.w #$20,-(sp) ; Offset 0 

trap #14 

addq.l #6, sp 

Parameter: 

ptr: Zeiger auf eine Bytefolge mit Soundbefehlen. Folgende Befehlscodes werden unter¬ 

stützt: 

$0x byte: Byte in Register x des Soundchips schreiben 

$80 byte: Byte in temporäres Register laden 

$81 bytel byte2 byte3 (drei Byte-Argumente!) 

bytel: Nummer des Soundregisters, in das der Wert des temporären 

Registers übertragen werden soll 
byte2: wird jeweils zum temporären Register addiert 

by te3: Endwert des temporären Registers, bei dem die “Schleife” abge¬ 

brochen wird 

$82-$FF byte: Anzahl der Jiffies (20 ms), die bis zum nächsten Kommando 
vergehen sollen (bei byte - 0 wird vollständig abgebrochen) 
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EgetPalette (XBIOS 85) - nur für TT-Videohardware 


Liest einen zusammenhängenden Bereich aus den TT-Farbregistem aus. 


Deklaration in C: 

void EgetPalette (WORD colorNum, WORD count, WORD *palettePtr); 


Aufruf in Assembler: 


pea 

move.w 
move.w 
move.w 
trap 
lea 


palettePtr 
count,-(sp) 
colorNum,-(sp) 
#$55,-(sp) 

#14 

$A (sp) , Sp 


; Offset 6 
; Offset 4 
; Offset 2 
; Offset 0 


Parameter: 

colorNum: Nummer des ersten auszulesenden Farbregisters 
count: Anzahl der auszulesenden Farbregister 

palettePtr: Zeiger auf zu übertragende Farbtabelle (muß auf eine gerade Adresse zeigen) 
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EgetShift (XBIOS 81) - nur für TT-Videohardware 

Fragt den Wert des Shiftmode-Registers im Video-Shifter des TT ab. 

Deklaration in C: 

WORD EgetShift (void); 

Aufruf in Assembler: 

move.w #$51,-{sp) ; Offset 0 

trap #14 

addq.l #2,sp 

Parameter: 

EgetShift(): Wert für das Modus-Register des TT-Shifters. Bitbelegung: 

Bit 15: Smear-Modus (siehe unter “EsetSmearO”) 

Bit 12: Hyper Mono (siehe unter “EsetGrayO”) 

Bit 10..8: Modus, wie er auch von “Getrez()” zurückgeliefert wird 

Bit 3..0: Nummer der Farbregister-Bank (siehe unter “EsetBankO”) 
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EsetBank (XBIOS 82) - nur für TT-Videohardware 

Die 256 Farbregister des TT sind in 16 verschiedene Bänke unterteilt. Mit diesem Kommando 
kann man die aktive Bank auswählen. 

Deklaration in C: 

WORD EsetBank (WORD bankNum); 


Aufruf in Assembler: 

move.w bankNum,-(sp) 
move.w #$52,-(sp) 

trap #14 

addq.l #4,sp 


; Offset 2 
; Offset 0 


Parameter: 

bankNum: Nummer der neuen aktiven Bank (0..15). Bei einem negativen Wert wird die 

Banknummer nicht geändert. 

EsetBankQ: bisherige Banknummer 
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EsetColor (XBIOS 83) - nur für TT-Videohardware 


Setzt (sofort, nicht erst im nächsten Vertical Blank) eines der 256Farbregister des TT-Shifters. 

Deklaration in C: 

WORD EsetColor (WORD colorNum, WORD color); 

Aufruf in Assembler: 

move.w color,-(sp) ; Offset 4 

move.w colorNum,-(sp) ; Offset 2 

move.w #$53,-(sp) ; Offset 0 

trap #14 

addq.l #6,sp 

Parameter: 

colorNum: Nummer des zu verändernden Farbregisters (0..255). Bei negativen Werten 

wird die eingestellte Farbe nicht verändert, 
color neue Farbe 

EsetColor(): bisheriger Wert 
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EsetGray (XBIOS 86) - nur für TT-Videohardware 


Der TT-Videochip kennt auch einen Graustufen-Modus, in dem man anstelle von 4096 
Farbtönen aus einer Graustufenpalette von 256 Tönen auswählen kann. In diesem Modus wird 
jeweils nur das untere Byte eines Eintrags in einem Farbregister benutzt. 

Deklaration in C: 

WORD EsetGray (WORD switch); 


Aufruf in Assembler: 

raove.w switch,-(sp) ; Offset 2 

move.w #$56,-(sp) ; Offset 0 

trap #14 

addq.l #4,sp 


Parameter: 

switch: ungleich 0: Graustufenmodus einschalten 

EsetGrayQ: alter Wert 
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EsetPalette (XBIOS 84) - nur für TT-Videohardware 


Setzt (sofort) einen zusammenhängenden Bereich von Farbregistem in der Farbpalette des 
TT-Shifters. 


Deklaration in C: 

void EsetPalette (WORD colorNum, WORD count, WORD *palettePtr); 

Aufruf in Assembler: 

pea palettePtr 

rnove. w count, - (sp) 

move.w colorNum,-(sp) 

move.w #$54,-(sp) 

trap #14 

lea $A (sp), sp 

Parameter: 

colorNum: Nummer des ersten zu ändernden Farbregisters 
count: Anzahl der zu setzenden Farbregister 

palettePtr: Zeiger auf zu übertragende Farbtabelle (muß auf eine gerade Adresse zeigen) 


; Offset 6 
; Offset 4 
; Offset 2 
; Offset 0 
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EsetShift (XBIOS 80) - nur für TT-Videohardware 

Setzt das Shiftmode-Register im Video-Shifter des TT. 

Deklaration in C: 

WORD EsetShift (WORD shftMode); 

Aufruf in Assembler: 

move.w newmode,-(sp) ; Offset 2 

move.w #$50,-(sp) ; Offset 0 

trap #14 

addq.l #4,sp 

Parameter: 

shftMode: Neuer Wert für das Modus-Register des TT-Shifters. Bitbelegung: 

Bit 15: Smear-Modus (siehe unter “EsetSmearO”) 

Bit 12: Hyper Mono (siehe unter “EsetGrayO”) 

Bit 10..8: Modus, wie er auch von “GetrezO” zurückgeliefert wird 

Bit 3..0: Nummer der Farbregister-Bank (siehe unter “EsetBankO”) 

EsetShift(): alter Wert des Registers 
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EsetSmear (XBIOS 87) - nur für TT-Videohardware 


Mit dieser Funktion kann der Smear-Modus des TT-Videobausteins umgeschaltet werden. Im 
Smear-Modus wird anstelle der Hintergrundfarbe (Farbe 0) die jeweils zuletzt dargestellte 
Farbe gezeichnet. 


Deklaration in C: 

WORD EsetSmear (WORD switch); 


Aufruf in Assembler: 

move.w switch,-(sp) ; Offset 2 

move.w #$57,-(sp) ; Offset 0 

trap #14 

addq.l #4,sp 


Parameter: 

switch: 0: Smear-Modus aus 

>0: Smear-Modus ein 

<0: nur den bisherigen Wert abfragen 

EsetSmear(): bisheriger Wert 
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Flopfmt (XBIOS 10) 


Formatiert eine Spur auf einer Diskette. 

Deklaration in C: 

WORD Flopfmt (void *buf, LONG filier, WORD devno, WORD spt, 

WORD trackno, WORD sideno, WORD interlv, LONG magic, 
WORD virgin); 


Aufruf in Assembler: 


move.w 

virgin,-(sp) 

/ 

Offset 

24 

move.1 

magic,-(sp) 

r 

Offset 

20 

move.w 

interlv,-(sp) 

r 

Offset 

18 

move.w 

sideno,-(sp) 

r 

Offset 

16 

move-w 

trackno,-(sp) 

/ 

Offset 

14 

move.w 

spt,-(sp) 

t 

Offset 

12 

mo vq. w 

devno,-(sp) 

f 

Offset 

10 

move.1 

#0, - (sp) 

} 

Offset 

6 

pea 

buf 

i 

Offset 

2 

move.w 

#$A, -(sp) 

t 

Offset 

0 

trap 

#14 




lea 

$1A (sp),sp 





Parameter: 

buf: Zeiger auf einen Speicherbereich, in dem die Daten für die Spur temporär 

gespeichert werden können (bei neun Sektoren pro Spur mindestens 8 KByte, 
muß bei höheren Sektorzahlen entsprechend vergrößert werden) 
filier: bei den “alten” TOS-Versionen unbenutzt (0). 

Ab TOS 1.02 kommt “filier” eine neue Bedeutung zu. Übergibt man als 
“interlv” -I, dann wird “filier” als Zeiger auf eine Tabelle von Sektomummem 
benutzt (16-Bit-Words). Damit hat man also die Möglichkeit, die Reihenfolge 
der Sektoren auf der Spur frei zu wählen, 
devno: 0: Laufwerk A: 

1: Laufwerk B: 

spt: Sektoren pro Spur (normalerweise 9). Wenn der “_FDC”-Cookie gesetzt ist, 

sind auch 18 Sektoren (“High-Density”) bzw. 36 Sektoren (“Extra-High- 
Density”) erlaubt. 
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Die Umschaltung zwischen den verschiedenen Schreibverfahren findet bei 13 
(HD) bzw. 26 (ED) statt. 

trackno: Nummer der Spur (0..79 oder ggfs, etwas darüber) 

sideno: 0 oder 1 (nur bei doppelseitigen Disketten) 

interlv: Bestimmt, wie viele physikalische Sektoren jeweils zwischen zwei logischen 

Sektoren liegen (normalerweise einer) 
magic: $87654321, sonst wird nicht formatiert 

virgin: Dieses Bitmuster wird beim Formatieren in jeden Sektor hineingeschrieben 

(normalerweise $e5e5, was jeweils abwechselnd gesetzte Bits bedeutet). Die 
oberen vier Bits dürfen auf keinen Fall gleichzeitig gesetzt sein, da dieses 
Bitmuster vom Disk-Controller als Kommando interpretiert und daher zu 
Chaos fuhren würde. 

Flopfmt(): 0: alles o.k. 

Bei Formatierfehlem wird eine durch 0 abgeschlossene Liste der fehlerhaften 
Sektoren in den Puffer geschrieben. 

Bemerkungen 

Auch das Desktop nutzt ab TOS 1.02 die Möglichkeit, eine Liste von Sektomummem zu über¬ 
geben. Dies erlaubt es, die Spuren untereinander so zu “spiralisieren”, daß beim Spurwechsel 
möglichst wenig Zeit mit dem Warten auf den “nächsten” Sektor vertan wird. 
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Floprate (XBIOS 41) - erst ab TOS 1.04 

Mit dieser TOS-Funktion kann man ab TOS 1.04 die Seekraten (Spurwechselzeiten) für beide 
Laufwerke setzen und abffagen. Auf älteren ROM-TOS-Versionen muß man die vorher 
undokumentierten Systemvariablen verwenden: 


TOS-Version 

Laufwerk A 

Laufwerk B 

1.00 

$A08 

$A0C 

1.02 

$A4E 

$A52 


Die Seekrate kann folgende Werte annehmen: 


Wert 

Seekrate 

0: 

6ms 

1: 

12ms 

2: 

2ms 

3: 

3ms 


Deklaration in C: 

WORD Floprate (WORD drive, WORD seekrate); 

Aufruf in Assembler: 

move.w seekrate,-(sp) ; Offset 4 

move.w drive,-(sp) ; Offset 2 

move.w #$29,-(sp) ; Offset 0 

trap #14 

addq.l #6,sp 

Parameter: 

drive: Nummer des Laufwerks (0: A, 1: B) 

seekrate: neue Seekrate oder -1, wenn die Seekrate nicht verändert werden soll 

FloprateO: vorherige Seekrate 

Bemerkungen 

Auf der folgenden Seite sehen Sie eine Beispielroutine zum portablen Setzen der Seekrate. 
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/* Portables Setzen der Floppy-Seekrate für alle TOS-Versionen 
(außer RAM-TOS 1.00). 

Parameter: genau wie bei XBIOS-Funktion "Floprate()" */ 

WORD SeekRate (WORD driv, WORD set) 

{ 

LONG stack; 

WORD Version; 

OSHEADER *sys; 

/* Zeiger auf OS-Header holen */ 

stack = Super (OL); 

sys = *((OSHEADER **)0x4f2) ; 

Version = sys->os_version; 

Super ((void *)stack); 

/* bei neuem TOS einfach "Floprate()" aufrufen V 
if (Version >= 0x104) 

return Floprate (driv, set); 

eise 

{ 

/* sonst Zeiger auf interne GEMDOS-Variablen 
berechnen */ 

WORD *sk, merk; 

if (Version == 0x102) 

sk = (WORD *)0xa4e; 

eise 

sk = (WORD *)0xa08; 

/* Laufwerk B: 2 WORDS dahinter */ 
if (driv) sk = &(sk[2]); 
merk = *sk; 

/* Wert nur bei ungleich -1 eintragen */ 
if (set != -1) *sk = set; 


} 


/* alten Wert immer zurückliefern */ 
return merk; 
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Floprd (XBIOS 8) 


Liest einen oder mehrere physikalische Sektoren von einer Diskette (vgl. BIOS-Funktion 

“RwabsO”). 


Deklaration in C: 

WORD Floprd (void *buf, LONG filier, WORD devno, WORD sectno, 
WORD trackno, WORD sideno, WORD count); 


Aufruf in Assembler: 



move.w 

count, - (sp) 

Offset 

18 

move .w 

sideno, -(sp) 

Offset 

16 

move.w 

trackno,-(sp) 

Offset 

14 

move.w 

sectno,-(sp) 

Offset 

12 

move.w 

devno,-(sp) 

Offset 

10 

move.1 

#0, -(sp) 

Offset 

6 (unbenutzt) 

pea 

buffer 

Offset 

2 

move.w 

#8, -(sp) 

Offset 

0 

trap 

#14 



lea .. 

$14(sp),sp 




Parameter: 


buffer: 

filier: 

devno: 

sectno: 

trackno: 

sideno: 

count: 

Floprd(): 


Zeiger auf Speicherbereich für die eingelesenen Sektoren 
unbenutzt 

0 (Laufwerk A:), 1 (Laufwerk B:) 

Nummer des Startsektors (normalerweise zwischen 1 und 9) 

Nummer der Spur (normalerweise zwischen 0 und 79) 

Seite der Diskette (0 bei einseitigen, 0 oder 1 sonst) 

Anzahl der zu lesenden Sektoren (die alle auf der gleichen Spur liegen müssen) 
0: mit Erfolg abgeschlossen 
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Flopver (XBIOS 19) 


Liest eine Reihe von physikalischen Sektoren von der Diskette und vergleicht mit einem 
gegebenen Speicherbereich. 


Deklaration in C: 

WORD Flopver (void *buf, LONG filier, WORD devno, WORD sectno, 
WORD trackno, WORD sideno, WORD count) 


Aufruf in Assembler: 



move.w 

count,-(sp) 

Offset 

18 

move.w 

sideno,-(sp) 

Offset 

16 

move.w 

trackno,-(sp) 

Offset 

14 

move.w 

sectno,-(sp) 

Offset 

12 

move.w 

devno,-(sp) 

Offset 

10 

move.1 

#0,-(sp) 

Offset 

6 (unbenutzt) 

pea 

buf 

Offset 

2 

move.w 

#$13,-(sp) 

Offset 

0 

trap 

#14 



lea 

$14(sp),sp 




Parameter: 


buf: 

filier: 

devno: 

sectno: 

trackno: 

sideno: 

count: 

Flopver(): 


Adresse des zu vergleichenden Speicherbereiches 
unbenutzt (kann auf 0 gesetzt werden) 

Nummer des Diskettenlaufwerks (0: A, 1: B) 

Nummer des Startsektors (normalerweise 1..9) 

Nummer der Spur (normalerweise 0..79) 

Diskettenseite (0..1) 

Anzahl der zu vergleichenden Sektoren (der letzte Sektor muß auf der gleichen 
Spur liegen wie der Startsektor) 

0: kein Fehler 

Ansonsten findet man bei “buf’ eine (durch 0 abgeschlossene) Liste der fehler¬ 
haften Sektoren. 
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Flopwr (XBIOS 9) 


Schreibt einen oder mehrere physikalische Sektoren auf eine Diskette. 


Deklaration in C: 

WORD Flopwr (void *buf, LONG filier, WORD devno, WORD sectno, 
WORD trackno, WORD sideno, WORD count); 


Aufruf in Assembler: 


rnove. w 

count,-(sp) 

; -> 24(sp) 

move.w 

sideno,-(sp) 

; Offset 16 

move.w 

trackno,-(sp) 

; Offset 14 

move.w 

sectno,-(sp) 

; Offset 12 

move.w 

devno,-(sp) 

; Offset 10 

move.1 

#0,-(sp) 

; Offset 6 (unbenutzt) 

pea 

buffer 

; Offset 2 

move.w 

#9,-(sp) 

; Offset 0 

trap 

#14 


lea 

$14(sp),sp 


Parameter: 



buffer: 

Zeiger auf Speicherbereich mit den zu schreibenden Sektoren 

filier: 

unbenutzt 


devno: 

0 (Laufwerk A:), 1 (Laufwerk B:> 

sectno: 

Nummer des Startsektors (normalerweise zwischen 1 und 9) 

trackno: 

Nummer der Spur (normalerweise zwischen 0 und 79) 

sideno: 

Seite der Diskette (0 bei einseitigen, 0 oder 1 sonst) 

count: 

Anzahl der zu schreibenden Sektoren (die alle auf der gleichen 


müssen) 


Flopwrf): 

0: mit Erfolg abgeschlossen 
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Getrez (XBIOS 4) - nur für ST/STE/TT-Videohardware 

Liefert die aktuelle Bildschirmauflösung. 


Deklaration in C: 

WORD Getrez (void); 


Aufruf in Assembler: 


move.w #4,-(sp) 

trap #14 

addq.l #2,sp 


Offset 0 


Parameter: 


GetrezQ: 


0: 320 * 200 (vier Planes) 

1: 640 * 200 (zwei Planes) 

2: 640 * 400 (ein Plane) 

4: 640 * 480 (vier Planes, nur beim TT) 

6: 1280 * 960 (ein Plane, nur beim TT) 

7 : 320 * 480 (acht Planes, nur beim TT) 

Alle anderen Werte sind für künftige Erweiterungen reserviert. 


Bemerkungen 

Sinnvoller ist es, statt dessen die Rückgabewerte der VDI-Funktion “v_opnv wk()” auszu wer¬ 
ten! Speziell dann, wenn eine Grafikkarte aktiv ist, hat der Rückgabewert von “GetrezO” de 
facto keinen Aussagewert! 
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Liest aus der Hardwareuhr das aktuelle Datum. 


Deklaration in C: 

LONG Gettime (void); 

Aufruf in Assembler: 

raove.w #$17,-(sp) ; Offset 0 

trap #14 

addq.l #2,sp 

Parameter: 

Gettime(): Aktuelles Datum: 

Bit 0..4: Sekunden (mit 2 zu multiplizieren) 

Bit 5.. 10: Minuten 

Bit 11..15: Stunden 

Bit 16..20: Tag 

Bit 21..24: Monat 

Bit 25..31: Jahr (1980 addieren!) 
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Giaccess (XBIOS 28) 


Setzt und liest Register im General-Instmments-Soundchip. 
Deklaration in C: 

char Giaccess (char data, WORD regno); 


Aufruf in Assembler: 


move.w 
move.w 
move.w 
trap 
addq.1 


regno, - (sp) 
data, - (sp) 
#$lC,-(sp) 
#14 
#6, sp 


; Offset 4 
; Offset 2 
; Offset 0 


Parameter: 

data: beim Schreibzugriff wird dieser 8-Bit-Wert in das entsprechende Register 

geschrieben 

regno: Nummer des GI-Registers (0..15). Beim Schreibzugriff wird zusätzlich Bit 7 

gesetzt, so daß sich dabei die Werte 128..143 ergeben. 

Wert des angegebenen GI-Registers 


Giacess(): 
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Ikbdws (XBIOS 25) 


Gibt eine Zeichenkette an den IKBD-Chip aus. 


Deklaration in C: 

void Ikbdws (WORD ent, const char *ptr); 


Aufruf in Assembler: 

pea ptr 

move.w ent, -(sp) 

move.w #$19,-(sp) 

trap #14 

addq.l #8,sp 


; Offset 4 
; Offset 2 
; Offset 0 


Parameter: 

ent: Anzahl der auszugebenden Bytes minus 1 
ptr: Zeiger auf die Bytefolge im Speicher 
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Initmous (XBIOS 0) 

Initialisiert die Mauszeigerroutinen. 

Deklaration in €: 

void Initmous (WORD type, PÄRAM *param, void *(*vec) {)); 

Aufruf in Assembler: 

pea vec 

pea param 

move.w type,-(sp) 

move.w #0,~(sp) 

trap #14 

lea 12(sp),sp 

Parameter: 

type: 0: Maus ausschalten 

1: Maus einschalten, relativer Modus 

2: Maus einschalten, absoluter Modus 

3: unbenutzt 

4: Maus einschalten, Tastaturemulation 

param: Zeiger auf eine Struktur folgenden Typs: 

typedef struct 

{ 

BYTE topmode; 

BYTE buttons; 

BYTE xparam; 

BYTE yparam; 

) PÄRAM; 

wobei die Strukturelemente folgende Bedeutung haben: 
topmode: 0: Y = 0 am unteren Rand 

1: Y = 1 am oberen Rand 

buttons: siehe IKBD-Beschreibung 

xparam, 

yparam: Zusätzliche Parameter, abhängig vom ausgewählten Modus 


; Offset 8 
; Offset 4 
; Offset 2 
; Offset 0 
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vec: 


Für den absoluten Modus muß sich direkt die folgende Struktur anschließen: 


typedef struct 
{ 


WORD xmax; 

/* 

Maximale X-Position */ 

WORD ymax; 

/* 

Maximale Y-Position */ 

WORD xinitial; 

/* 

Anfangsposition X */ 

WORD yinitial; 

/* 

Anfangsposition Y */ 

} EXTRA; 



Zeiger auf Maustreiberroutine 





BIOS und XBIOS 


127 


Iorec (XBIOS 14) 


Liefert einen Zeiger auf eine gerätespezifische Infomationsstruktur folgenden Formats: 


typedef struct 
{ 

LONG ibuf; 
WORD ibufsiz; 
WORD ibufhd; 
WQRD ibuftl; 
WORD ibuflow; 
WORD ibufhi; 

} IOREC; 


/* Zeiger auf den Puffer */ 

/* Länge des Puffers */ 

/* nächste Schreibposition */ 
/* nächste Leseposition */ 

/* "untere Wassermarke" */ 

/* "obere Wassermarke" */ 


Für die serielle Schnittstelle schließt sich direkt ein entsprechender Puffer für die Ausgabe an. 

Die beiden letzten Zeiger werden nur für die serielle Schnittstelle im XON/XOFF- oder RTS/ 
CTS-Betrieb genutzt. Fällt der “Zeichenpegel” im Puffer unter die “untere Wassermarke”, 
wird das Sendegerät zum Senden weiterer Zeichen aufgefordert. Übersteigt der Pegel die 
“obere Wassermarke”, wird das Sendegerät aufgefordert, keine weiteren Zeichen zu senden. 


Deklaration in C: 

IOREC *Iorec (WORD devno); 


Aufruf in Assembler: 

move.w devno,~(sp) ; Offset 2 

move.w #$E,-(sp) ; Offset 0 

trap #14 

addq.l #4,sp 

Parameter: 

devno: Gerätenummer: 

0: RS 232 

1: IKBD (Tastatur) 

2: MIDI 

Iorec(): Zeiger auf IOREC-Struktur 
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Jdisint (XBIOS 26) 


Sperrt den angegebenen Interrupt des MFP 68901. 

Deklaration in C: 

void Jdisint (WORD intno); 


Aufruf in Assembler: 

move.w intno,-(sp) ; Offset 2 

move.w #$1A,-(sp) ; Offset 0 

trap #14 

addq.l #4,sp 


Parameter: 

intno: Nummer des zu sperrenden Interrupts (0..15) 


Jenabint (XBIOS 27) 


Schaltet den angegebenen Interrupt des MFP 68901 ein. 

Deklaration in C: 

void Jenabint (WORD intno); 


Aufruf in Assembler: 

move.w intno,-(sp) ; Offset 2 

move.w #$1B,-(sp) ; Offset 0 

trap #14 

addq.l #4,sp 


Parameter: 

intno: Nummer des betreffenden Interrupts (0..15) 
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Kbdvbase (XBIOS 34) 

Liefert einen Zeiger auf eine Struktur folgender Form: 

typedef struct 

{ 

void (*midivec) (); /* Midi-Eingabe */ 

void (*vkbderr) (); /* Tastatur-Fehler */ 

void (*vmiderr)(); /* MIDI-Fehler */ 

void <*statvec)(); /* Status von IKBD lesen */ 

void (*mousevec)(); /* Mausabfrage */ 
void (*clockvec)(); /* Uhrzeitabfrage */ 
void (*joyvec)(); /* Joystickabfrage */ 

void (*midisys)(); /* MIDI-Systemvektor */ 

void (*ikbdsys) (); /* IKBD-Systemvektor */ 

WORD drvstat; /* IKBD-Treiberstatus */ 

} KBDVECS; 

midivec: Routine, die vom MIDI-Port empfangene Bytes (in DO) in einen Puffer 

schreibt 

vkbderr, vmiderr: werden beim Überlauf von Daten von der Tastatur oder vom MIDI-Port 

aufgerufen 

statvec, mousevec, 

clockvec, joyvec: Zeiger auf die Routinen, die die entsprechenden Informationspakete 
von MIDI oder IKBD verarbeiten. 

Die Adresse des “packets” wird in AO und auf dem Stack übergeben. 
Die Routinen sollten mit einem RTS abgeschlossen sein und nicht länger 
als 1 ms laufen. 

midisys, ikbdsys: werden beim Eintreffen von Daten am entsprechenden Port aufgerufen. 

“midisys" springt indirekt durch “midivec”; “ikbdsys” verzweigt in eine 
der vier in Frage kommenden Unterroutinen (s.o.), 

drvstat: Wenn diese Statusvariable ungleich 0 ist, dann verschickt der IKBD 

gerade ein “packet”. 

Deklaration in C: 

KBDVECS *Kbdvbase (void); 
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Aufruf in Assembler: 

move.w #$22,-(sp) ; Offset 0 

trap #14 

addq.l #2,sp 


Parameter: 

Kbdvbase(): Zeiger auf KBDVECS-Struktur 
Bemerkungen 

Bevor man entweder Daten in eine der Routinen “einspeisen” oder einen der Vektoren ändern 
kann, muß man sichergehen, daß momentan nicht gerade ein “packet” verschickt wird. Dann 
sollte man alle Interrupts sperren und anschließend nochmals testen, ob tatsächlich kein 
“packet” mehr unterwegs ist. Erst dann darf man Weiterarbeiten! 
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Kbrate (XBIOS 35) 


Setzt die Tastatur-Wiederholrate oder fragt sie ab. 

Deklaration in C: 

WORD Kbrate (WORD initial, WORD repeat); 

Aufruf in Assembler: 

move.w repeat,- (sp) ; Offset 4 

move.w initial,- (sp) ; Offset 2 

move.w #$23,-(sp) ; Offset 0 

trap #14 

addq.l #6,sp 


Parameter: 

initial: Ansprechzeit bis zur ersten Wiederholung (initial/(20 ms)) oder -1 (keine 

Änderung) 

repeat: Wiederholgeschwindigkeit (repeat/(20 ms)) oder -1 (keine Änderung) 

Kbrate(): Bit 0..7: bisheriger Wert von “repeat” 

Bit 8.. 15: bisheriger Wert von “initial” 
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Keytbl (XBIOS 16) 

Setzt die Adressen der Tastencode-UmwandlungstabelLen. Ein Code wird umgerechnet, 
indem der Scancode der betreffenden Taste als Index in die Tabelle (von ASCD-Zeichen) 
verwendet wird. Zurückgeliefert wird ein Zeiger auf eine Struktur folgender Form: 

typedef struct 

{ 

char *unshift; /* Tabelle für "normale" Tastendrücke */ 

char *shift; /* Tabelle für Tastendrücke mit "Shift" */ 

char *capslock; /* Tabelle für Tastendrücke bei "Capslock" */ 

} KEYTAB; 

Deklaration in C: 

KEYTAB *Keytbl (char *unshift, char *shift, char *capslock); 

Aufruf in Assembler: 

pea capslock 

pea shift 

pea unshift 

move.w #$10,-(sp) 

trap #14 

lea $E(sp),sp 

Parameter: 

unshift: Zeiger auf “unshift”-Tabelle (oder—1, wenn keine neue Adresse gesetzt werden 

soll) 

shift: Zeiger auf “shift”-Tabelle (oder -1, wenn keine neue Adresse gesetzt werden 

soll) 

capslock: Zeiger auf “capslock”-Tabelle (oder -1, wenn keine neue Adresse gesetzt 

werden soll) 

Keytbl(): Zeiger auf KEYTAB-Struktur 

Bemerkungen 

Jede der Tabellen hat nur 12S Einträge, obwohl es einige Tastenkombinationen mit höherem 
Scancode gibt (siehe Tabelle). 


; Offset 10 
; Offset 6 
; Offset 2 
; Offset 0 
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Logbase (XBIOS 3) - nur für ST/STE/TT -Hardware 


Liefert die Anfangsadresse des logischen Bildschirmspeichers (das ist derjenige, der bei allen 
Grafikoperationen angesprochen wird). 


Deklaration in C: 

void *Logbase (void); 

Aufruf in Assembler: 

move.w #3,~(sp) ; Offset 0 

trap #14 

addq.l #2,sp 

Parameter: 

Logbase(): Anfangsadresse des logischen Bildschirmspeichers 
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Metainit (XBIOS48) 


Mit dieser Funktion kann man Informationen über die aktuell installierte Meta-DOS-Version 
(und die von ihr installierten Geräte) erfragen. Da nicht jeder Meta-DOS benutzt und es 
deshalb nicht überall installiert ist, muß man folgendermaßen Vorgehen: 

1. METAINFO-Struktur vollständig löschen (also 16 Nullbytes). 

2. Metainit() aufrufen 

3. Testen, ob “version” noch immer einen Nullzeiger enthält (dann nämlich ist Meta-DOS 
nicht installiert) 

typedef struct 

{ 

ULONG drivemap; /* Tabelle mit Bits für die Meta-DOS- 

Geratetreiber "A".."Z" (Bit 0: "A") */ 
char *version; /* Zeichenkette mit Namen und 

Versionsnummer von Meta-DOS */ 

LONG reserved[2]; 

) METAINFO; 

Damit läßt sich schon mal feststellen, ob Meta-DOS installiert ist und welche physikalischen 
Gerätenummem belegt sind. Diese Geräte kann man dann mit weiteren, für Meta-DOS 
reservierten XBIOS-Aultufen (Nummern 48 bis 63) ansteuem. 


Deklaration in C: 

void Metainit (METAINFO *buffer); 

Aufruf in Assembler: 

pea buffer ; Offset 2 

move.w #$30,-(sp) ; Offset 0 

trap #14 

addq.l #6,sp 


Parameter: 

buffer: Zeiger auf METAINFO-Struktur, die von Meta-DOS ausgefüllt wird 
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Mfpint (XBIOS 13) 


Setzt die Interrupt-Vektoren des MEP 68901. Dabei wird jeweils der alte Wert überschrieben. 


Deklaration in C: 

void Mfpint (WORD interno, void (*vector) ()); 


Aufruf in Assembler: 

pea vector 

move.w interno,-(sp) 

move.w #$D,-(sp) 
trap #14 

addq.l #8,sp 


; Offset 4 
; Offset 2 
; Offset 0 


Parameter: 

interno: Nummer des zu ändernden Vektors (0..15) 

vector: Neue Adresse für die betreffende Interrupt-Routine 
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Midiws (XBIOS12) 


Gibt eine Bytefolge auf dem MEDI-Port aus. 


Deklaration in C: 

void Midiws (WORD ent, cönst char *ptr); 


Aufruf in Assembler: 

pea ptr 

move.w cnt,-(sp) 

move.w #$C,-(sp) 

trap #14 

addq.l #8,sp 


; Offset 4 
; Offset 2 
; Offset 0 


Parameter: 

ent: Anzahl der auszugebenden Bytes minus 1 
ptr: Zeiger auf Bytefolge 
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NVMaccess (XBIOS 46) - nur auf dem TT 


Die Echtzeituhr des TT verfügt über 50 Bytes nichtflüchtiges (“non volatile”) RAM, das man 
daher sehr gut für Konfigurationszwecke benutzen kann. Die letzten beiden Bytes werden als 
Prüfsumme benutzt. “NVMaccessQ” dient zur Verwaltung dieses RAMs. 

Die Belegung des NVMs (“non volatile memory”) wird von Atari festgelegt. Die Benutzung 
für nicht von Atari dokumentierte Zwecke kann und wird zu schwerwiegenden Problemen 
führen! 

Bislang ist über die Verwendung des NVMs noch nicht entschieden. Im Bedarfsfall sollte man 
der zuständigen Atari-Vertretung Vorschläge unterbreiten. 


Deklaration in C: 

WORD NMVaccess (WORD op, WORD Start, WORD count, BYTE *buffer); 


Aufruf in Assembler: 


pea 

buffer 

; Offset 

move.w 

count,-(sp) 

; Offset 

raove.w 

Start, -(sp) 

; Offset 

move.w 

op,-(sp) 

; Offset 

raove.w 

#$2E,-(sp) 

; Offset 

lea 

$C(sp),sp 



Parameter: 

op: 


Start: 

count: 

NVMaccess(): 


0: NVM auslesen, dabei Prüfsumme überprüfen 

1: NVM beschreiben, Prüfsumme überprüfen und neu setzen 

2: NVM initialieren und Prüfsumme setzen 

Nummer des Startbytes 
Anzahl der zu übertragenden Bytes 
OK (0): alles in Ordnung 

EBADRQ (-5): Argumente nicht im erlaubten Bereich 

EGENRL(-12): Prüfsumme war nicht konsistent (beim Lesen 

werden die Bytes trotzdem übertragen) 
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Offgibit (XBIOS 29) 


Löscht Bits im “PORT A”-Register des Gl-Chips. 

Deklaration in C: 

void Offgibit (WORD bitno); 

Aufruf in Assembler: 

move.w bitno,-(sp) ; Offset 2 

move.w #$lD,-(sp) ; Offset 0 

trap #14 

addq.l #4,sp 

Parameter: 

bitno: Mit dieser Bitmaske wird der aktuelle Zustand des Registers logisch undiert. 


Ongibit (XBIOS 30) 


Setzt Bits im “PORT A”-Register des Gl-Chips. 

Deklaration in C: 

void Ongibit (WORD bitno); 

Aufruf in Assembler: 

move.w bitno,-(sp) ; Offset 2 

move.w #$1E,-(sp) ; Offset 0 

trap #14 

addq.l #4,sp 


Parameter: 

bitno: Mit dieser Maske wird der aktuelle Zustand des Registers logisch oderiert. 
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Physbase (XBIOS 2) - nur für ST/STE/TT-Videohardware 

Liefert die Anfangsadresse des physikalischen Bildschirmspeichers (das ist genau der 
Speicherbereich, den man auf dem Bildschirm sieht). 

Deklaration in C: 

void *Physbase (void); 

Aufruf in Assembler: 

rnove.w #2,-(sp) ; Offset 0 

trap #14 

addq.l #2,sp 

Parameter: 

Physbase(): Anfangsadresse des physikalischen Bildschirmspeichers. 
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Protobt (XBIÖS 18) 


Baut im Speicher einen Bootsektor auf. 


Deklaration in C: 


void Protobt (void *buf, LONG serialno, WORD disktype, 
WORD execflag); 


Aufruf in Assembler: 


move.w 

execflag,-(sp) 

; Offset 12 

move.w 

disktype,-(sp) 

; Offset 10 

move.1 

serialno,-(sp) 

; Offset 6 

pea 

buf 

; Offset 2 

move.w 

trap 

lea 

#$12,-(sp) 

#14 

$E (sp),sp 

; Offset 0 

Parameter: 

buf: 

Zeiger auf einen 512 Bytes langen Puffer, der den neuen Bootsektor 
soll 

serialno: 

-1: 

>= $01000000: 
sonst: 

gleiche Seriennummer wie beim letzten Mal 
zufällige Seriennummer berechnen 
neue Seriennummer 

disktype: 

-1: Typ nicht verändern 

0: 40 Spuren, einseitig (180 K) 

1: 40 Spuren, doppelseitig (360 K; MS-DOS-Standardformat) 

2: 80 Spuren, einseitig (360 K; Standard einseitig) 

3: 80 Spuren, doppelseitig (720 K; Standard doppelseitig) 


execflag: 


- 1 : 

0 : 

1 : 


High-Density 

(nur wenn im “_FDC”-Cookie der Wert für HD-Unterstützung eingetra¬ 
gen ist) 

Extra-High-Density 

(nur wenn im “_FDC”-Cookie der Wert für ED-Unterstützung eingetra¬ 
gen ist) 
nicht ändern 

Bootsektor nicht ausführbar 

Bootsektor ausführbar (siehe Aufbau von Bootsektoren) 
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Bemerkungen 

Damit die Diskette auch auf MS-DOS-Sy stemen lesbar ist, muß man manuell die hexadezimalen 
Werte $E9 $00 $4E in die ersten drei Bytes des Bootsektors eintragen. 

“ProtobtO” neigt zu Verschwendung: auf einer normalen 720K-Diskette wird Platz für fünf 
FAT-Sektoren angelegt, obwohl drei völlig reichen würden. 
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Prtblk (XBIOS 36) 


Ähnelt der normalen Hardcopy-Funktion (von der aus sie auch aufgerufen wird). 
Allerdings ist sie um einiges flexibler; sie erwartet einen Parameterblock folgender Form: 


typedef struct 
/ 



LONG pb_scrptr; 

/* 


WORD pb offset; 

/* 


WORD pb_width; 

/* 


WORD pb_height; 

/* 


WORD pb_left; 

/* 


WORD pb right; 

/* 


WORD pb screz; 

/* 


WORD pb prrez; 

/* 


LONG pb_colptr; 

/* 


WORD pbjprtype; 

/* 


WORD pb_jprport; /* 

LONG pbjnask; /* 

} PBDEF; 


Zeiger auf Bildschirmanfang */ 
dazu zu addierender Offset */ 
Bildschirmbreite in Punkten */ 
Bildschirmhöhe in Punkten */ 

Linker Rand in Punkten */ 

Rechter Rand in Punkten */ 
Auflösung */ 

Druckertyp Atari/Epson */ 

Zeiger auf Farbpalette 
(zum Beispiel $FF8240) */ 

0: Atari Matrix monochrom, 

1: Atari Matrix farbig, 

2: Atari Typenrad monochrom, 

3: Epson Matrix monochrom */ 
Schnittstelle Centronics/RS 232 */ 
Zeiger auf Halbtonmaske */ 


Insbesondere muß man beachten, daß die Summe von “pb_width”, “pbjeft” und “pb_right” 
genau die tatsächliche Bildschirmbreite ergeben muß. 

Ferner muß man vorher “_dumpflg” ($4EE) auf 1 setzen - denn sonst passiert überhaupt 
nichts. Der Druckvorgang kann mit '‘Altemate/Help” abgebrochen werden. 

Nach der Rückkehr sollte man “_dumpflg” wieder auf -1 setzen. 


Deklaration in C: 

void Prtblk (PBDEF *defptr); 
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Aufruf in Assembler: 

move.w # 1,_dumpflg 

pea defptr ; Offset 2 

move.w #$24,-(sp) ; Offset 0 

trap #14 

addq.l #6,sp 

move.w #-1,_dumpflg 


Parameter: 

defptr: Zeiger auf PBDEF-Struktur 
Bemerkungen 

Gibt über die Systemvektoren “prvjsto”, “prvjst”, “prv_auxo” bzw. “prv_aux” aus. 

Die offizielle Dokumentation (“Hitchhiker’s Guide to the BIOS”) führt diese Funktion zwar 
auf, schweigt sich allerdings über alle Parameter aus. 
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Puntaes (XBIOS 39) 


Das AES wird nur gestartet, wenn “os_magic” im OSHEADER auf die korrekte magische 
Zahl ($87654321) zeigt. “PuntaesO” setzt dieses Flag (sofern möglich) zurück und bootet dann 
das System neu. 

Deklaration in C: 

void Puntaes (void); 

Aufruf in Assembler: 

move.w #$27,-(sp) ; Offset 0 

trap #14 

addq.l #2,sp 
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Random (XBIOS 17) 


Mit dieser Funktion kann man sich eine 24-Bit-Zufallszahl berechnen lassen. Der Anfangswert 
nach Systeminitialisierung sollte stets unterschiedlich sein, da mit dem Wert des vertikalen 
Zeilenzählers (im Videochip) initialisiert wird. 

Gleichwohl handelt es sich nicht um einen echten Hardware-Zufallszahlengenerator (wie zum 
Beispiel bei Ataris 8-Bittem). Statt dessen wird nach dem Algorithmus 

S = (S * 3.1415926...) + 1 

verfahren. Zurückgeliefert wird die Zahl S (um acht Bits nach rechts verschoben). Das 
Verhalten für die gesamte Zahl ist recht gut, die Abfrage einzelner Bits kann jedoch gefährlich 
sein (im Sinne einer verminderten “Zufälligkeit”). 

Im Zweifelsfall sollte man sich zunächst eine Reihe von Zahlenwerten ausgeben lassen, die 
“zufällig” sein sollen! 


Deklaration in C: 

LONG Random (void); 


Aufruf in Assembler: 

move.w #$11,-(sp) ; Offset 0 

trap #14 

addq.l #2,sp 


Parameter: 

RandomQ: 24-Bit-Zufallszahl 
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Rseonf (XBIOS 15) 

Setzt Parameter für die serielle Schnittstelle. “Früher” setzte diese Funktion einfach nur die 
entsprechenden Register im MFP-Baustein. 

Seit der Einführung des Atari TT ist nicht mehr ohne weiteres klar, welcher Hardwarebaustein 
für die serielle Schnittstelle eingesetzt wird (siehe XBIOS-Einführung und “BconmapO”). 

Daher muß man “RsconfO” besonders vorsichtig einsetzen. Das heißt: 

1. Aktuelle Einstellungen mit Rseonf (-1, -1, -1, -1, -1, -1) abffagen. 

2. Nur die interessanten Bits modifizieren. 

3. Die neuen Werte setzen. 


Dadurch, daß die serielle Schnittstelle nicht mehr unbedingt durch einen MFP angesteuert 
wird, werden die benutzbaren Werte folgendermaßen eingeschränkt: 


ucr: 


rsr: 

tsr: 

scr: 


Bit 5..6: Wortlänge (00: 8,01: 7, 10: 6, 11: 5) 

Bit 3..4: Stopbits (01: 1, 10: 1.5, 11: 2,00: ungültig) 

Bit 2: parity (0: nein, 1: ja) 

Bit 1: 0: odd parity, 1: even parity (nur sinnvoll, wenn auch Bit 2 gesetzt ist) 

nicht benutzbar 

Bit 3: 1: break 

nicht benutzbar 


Technisch nicht mögliche Werte müssen ignoriert werden. 


Schon deshalb sollte man sich nie darauf verlassen, daß wirklich alle Einstellungen vorgenom¬ 
men worden sind (sondern den Rückgabewert inspizieren!). 

Deklaration in C: 

ULONG Rseonf (WORD speed, WORD flowctl, WORD ucr, WORD rsr, 

WORD tsr, WORD scr); 
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Aufruf in Assembler: 

move.w scr,-(sp) 

move.w tsr,-(sp) 

move.w rsr,-(sp) 

move.w ucr,-(sp) 

move.w flowctl,-(sp) 
move.w speed,-(sp) 

move.w #$F,-(sp) 

trap #14 

lea $E(sp),sp 

Parameter: 

speed: -1: nicht ändern 

0: 19200 Baud 

1: 9600 Baud 

2: 4800 Baud 

3: 3600 Baud 

4: 2400 Baud 

5: 2000 Baud 

6: 1800 Baud 

7: 1200 Baud 

8: 600 Baud 

9: 300 Baud 

10: 200 Baud 

11: 150 Baud 

12: 134 Baud 

13: 110 Baud 

14: 75 Baud 

15: 50 Baud 

flowctl: “1: nicht ändern 

0: keine Flußkontrolle 

1: XON/XOFF (CTRL-S, CTRL-Q) 

2: RTS/CTS 

3: RTS/CTS und XON/XOFF 

ucr, tsr, rsr, scr: entweder die neuen Werte für die Register oder -1 (nicht verändern) 

Rsconf(): in gepackter Form die Werte des ucr-, rsr- und tsr-Registers (Bit 31..24: 

ucr, Bit 23.,16: rsr, Bit 15..8: tsr, Bit 7..0: scr) 


; Offset 12 
; Offset 10 
; Offset 8 
; Offset 6 
; Offset 4 
; Offset 2 
; Offset 0 
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Bemerkungen 

Ab TOS 1.04 kann man mit “Rsconf(-2,-l-1,-1-1)” die letzte eingestellte Baudrate 
abfragen. 
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Scrdmp (XBIOS 20) 


Druckt den aktuellen Bildschirminhalt aus. Der Druckvorgang kann durch Betätigen von 
“Altemate/Help” abgebrochen werden (siehe auch “SetprtO”). 


Deklaration in C: 

void Scrdmp (void) ; 

Aufruf in Assembler: 

move.w #$14,-(sp) ; Offset 0 

trap #14 

addq.l #2,sp 

Bemerkungen 

Springt über den Systemvektor “scr_dump”. Die dort eingetragene Funktion ruft normaler¬ 
weise die XBIOS-Funktion “Prtblk()” auf. 

Die Hardcopy-Routine funktioniert nur für eine ausgeschränkte Auswahl von Druckern (siehe 
“SetprtO”) und beim TT auch nicht in allen Auflösungen. 
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Setcolor (XBIOS 7) - nur für ST/STE/TT-Videoliardware 


Setzt ein Farbregister auf einen neuen Wert oder fragt nur den Wert ab. 


Deklaration in C: 

WORD Setcolor (WORD colorNum,.WORD color); 


Aufruf in Assembler: 


move.w 
move.w 
move.w 
trap 
addq.1 


color, - (sp) 
colorNum,-(sp) 
#7,-(sp) 

#14 
#6, sp 


Offset 4 
Offset 2 
Offset 0 


Parameter: 


color: 

colorNum: 

Setcolor(): 


Neuer Farbwert oder —1, falls das Register nicht geändert werden soll 
Nummer des anzusprechenden Farbregisters (0..15) 

Bisheriger Wert des Farbregisters 
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Setpalette (XBIOS 6) - nur für ST/STE/TT-Videohardware 


Neue Farbpalette an die Video-Hardware übergeben (geschieht erst im nächsten Vertical 
Blank). 

Deklaration in C: 

void Setpalette (WORD *palettePtr); 

Aufruf in Assembler: 

pea palettePtr ; Offset 2 

move.w #6,-(sp) ; Offset 0 

trap #14 

addq.l #6,sp 

Parameter: 

palettePtr: Zeiger auf eine Tabelle aus sechzehn 16-Bit-Worten, die die neue Farbpalette 

enthalten (wobei jeweils die untersten zwölf Bits für die RGB-Werte benutzt 
werden). Muß auf einer geraden Adresse liegen. 

Bemerkungen 

Das hier benutzte Format wird.bei künftigen Auflösungen (z.B. 320 * 480 in 256 Farben beim 
Atari TT) nicht mehr ausreichen! Statt dessen verwende man besser die entsprechenden VDI- 
Funktionen! 

“Setpalette” ist ein “delayed action call". Zu deutsch: die Daten werden nicht sofort, sondern 
erst etwas später verarbeitet. Da nur ein Zeiger auf die Farbtabelle übergeben wird, muß man 
schon selbst dafür sorgen, daß der Zeiger im nächsten Vertical Blank noch auf etwas Sinn¬ 
volles zeigt. 
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Setprt (XBIOS 33) 


Setzt oder liest die aktuelle Druckereinstellung. Diese Einstellung wird von fast allen anderen 
Betriebssystemteilen mit Nichtachtung gestraft (Ausnahmen: “ScrdmpO” und “PrtblkO”). 
Beim BIOS liegt das an einem Fehler, der leider in allen bekannten TOS-Versionen 
gleichermaßen vorhanden ist. 

In eigenen Programmen sollte man zumindest die Wahl der Schnittstelle (seriell/parallel) und 
die Einzelblatt-/Endlospapiereinstellung auswerten. 


Deklaration in C: 

WORD Setprt (WORD config); 


Aufruf in Assembler: 

move.w config,-(sp) ; Offset 2 

move.w #$21,-(sp) ; Offset 0 

trap #14 

addq.l #4,sp 


Parameter: 


config: —1: Konfiguration auslesen 

neues Konfigurationsbyte: 

Bitbelegung: 

BitO: Matrixdrucker 
Bit 1: monochrom 
Bit 2: Atari-Drucker (1280 Punkte) 

Bit 3: normale Qualität 
Bit 4: Centronics 
Bit 5: Endlospapier 
alle weiteren Bits sind zur Zeit nicht benutzt 
Setprt(): aktuelle Konfiguration 


Typenraddrucker 

farbig 

Epson-Drucker (960 Punkte) 
hohe Qualität (nur bei 1280 P.) 
RS 232 

Einzelblattpapier 


Bemerkungen 

Bit 2 ist eigentlich nur für die XBIOS-eigene Hardcopy-Routine interessant. 
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Setscreen (XBIOS 5) - nur für ST/STE/TT-Videohardware 

Dient zum Ändern von Bildschirmspeicheradressen und Auflösung. 


Deklaration in C: 

void Setscreen (void *logLoc, void *physLoc, WORD res); 


Aufruf in Assembler: 


move.w 
move.1 
move.1 
rrtove. w 
trap 
lea 


res, - <sp) 
physLoc,-(sp) 
logLoc, -(sp) 
#5,-(sp) 

#14 

$C (sp), sp 


; Offset 10 
; Offset 6 
; Offset 2 
; Offset 0 


Parameter: 

logLoc: -1: Adresse des logischen Bildschirmspeichers nicht ändern 

sonst: neue Anfangsadresse 

physLoc: -1: Adresse des physikalischen Bildschirmspeichers nicht ändern 

sonst: neue Anfangsadresse (muß beim ST auf einer 256-Byte-Grenze liegen) 
res: -1: Auflösung nicht ändern 

sonst: neue Bildauflösung 

Bemerkungen 

Bei Änderungen der Bildauflösung wird der VT52-Emulator automatisch initialisiert (z.B. der 
Cursor in die linke obere Ecke gesetzt). 

Bitte anschließend mit “Physbase()”, “Logbase()” und “Getrez()” überprüfen, ob der Funktions¬ 
aufruf erfolgreich war: niemand garantiert, daß man mit jedem Bildschirmtreiber und jeder 
Grafikkarte all diese Parameter verändern kann! 

Vorsicht, wenn gleichzeitig die Systemvariable “screenpt” benutzt wird! 
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Settime (XBIOS 22) 

Setzt die Hardware-Uhr auf ein neues Datum. Bei den Mega-STs wird nicht die IKBD-Uhr, 
sondern die batteriegepufferte Uhr gesetzt. 

Deklaration in C: 

void.Settime (LONG datetime); 

Aufruf in Assembler: 

move.l datetime,-(sp) ; Offset 2 

move.w #$16,-(sp) ; Offset 0 

trap #14 

addq.l #6,sp 


Parameter: 

datetime: Codiertes Datum: 

Bit 0..4: Sekunden (Wert 0..59 durch 2 dividieren) 

Bit 5..10: Minuten 

Bit 11..15: Stunden 

Bit 16. .20: Tag 

Bit 21..24: Monat 

Bit 25..31: Jahr (1980 subtrahieren) 
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Ssbrk (XBIOS 1) 


Reserviert Speicherplatz am Ende des physikalischen Speicherbereichs und kann nur vor der 
Initialisierung von GEMDOS benutzt werden (diese Funktion ist bei sämtlichen ROM-TOS- 
Versionen nur eine Dummy-Routine, die überhaupt nichts bewirkt!). 


Deklaration in C: 

LONG Ssbrk (WORD amount); 

Aufruf in Assembler: 

move.w amount,-(sp) ; Offset 2 

move.w #l,-(sp) ; Offset 0 

trap #14 

addq.l #6,sp 


Parameter: 

amount: Anzahl der zu reservierenden Bytes 

Ssbrk(): Anfangsadresse des allozierten Speicherbereichs 
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Supexec (XBIOS 38) 


Führt ein (durch RTS abgeschlossenes) Unterprogramm im Supervisor-Modus aus. 


Deklaration in C: 

LONG Supexec (LONG (*codeptr)()); 


Aufruf in Assembler: 


pea 

move.w 
trap 
addq.1 


codeptr 
#$26,-(sp) 
#14 
#6, sp 


; Offset 2 
; Offset 0 


Parameter: 

codeptr: Anfangsadresse der betreffenden Routine 

Supexec(): Der Return-Wert der aufgerufenen Funktion wird von “SupexecO” an den 

Aufrufer zurückgereicht. 


Vsync (XBIOS 37) 

Wartet, bis ein Vertical-BIank-Interrupt aufgetreten ist. Für zeitkritische Abfragen (beispiels¬ 
weise für Fine-Scrolling) sollte man besser direkt den Zeilenzähler im Shifter abfragen! 

Deklaration in C: 

void Vsync (void) ; 


Aufruf in Assembler: 

move.w #$25,-(sp) 

trap #14 

addq.l #2,sp 


; Offset 0 
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Setzt und startet die MFP 68901-Timer. 


Deklaration in C: 

void Xbtimer (WORD timer, WORD control, WORD data, void (*vec)()); 

Aufruf in Assembler: 

pea vec ; Offset 8 

move.w data,-(sp) ; Offset 6 

move.w control,-(sp) ; Offset 4 

move.w timer,-(sp) ; Offset 2 

move.w #$lF,-(sp) ; Offset 0 

trap #14 

lea $C(sp),sp 

Parameter: 

timer: Nummer des Timers: 

0: Timer A: kann für eigene Programme benutzt werden 

1: Timer B: Horizontal-Blank-Interrupt 

2: Timer C: 200 Hz Systemtimer 

3: Timer D: Baudraten-Generator 

control, data: Werte für die entsprechenden Timer-Register 
vec: Zeiger auf die dazugehörige Interrupt-Routine 
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Kapitel 2: GEMDOS 

Einleitung 

Das erste System, auf dem GEM implementiert wurde, war bekanntlich der IBM PC unter MS- 
DOS. Als Ende 1984 GEM auf den Motorola-Prozessor portiert wurde, gab es weder fertige 
STs noch Entwicklungswerkzeuge noch ein Betriebssystem, auf das man hätte aufbauen 
können. 

So nahmen die Entwickler den Umweg über eine Apple “Lisa”, auf der CP/M 68K (ebenfalls 
ein DOS von Digital Research) lief. Wer das damalige Entwicklungspaket von Atari kennt, 
erinnert sich sicherlich noch an den Alcyon-C-Compiler oder “LINK68” und “RELMOD” 
(das CP/M-68K-Programme in GEMDOS-Programme konvertierte). Aus verschiedenen 
Gründen kam CP/M 68K nicht als endgültiges Betriebssystem in Frage (ein Grund war das 
fehlende hierarchische Dateisystem). Daher entschloß man sich bei Atari und Digital 
Research, als Grundlage für GEM auf Motorola-Rechnem einen völlig neuen Unterbau zu ent¬ 
wickeln, eben “GEMDOS” (“GEM Disk Operating System”). Und so entwickelte Digital- 
Research-Programmierer Jason Loveman in kürzester Zeit ein neues DOS, das in den meisten 
Details MS-DOS 2.0 entspricht. Leider führte die Eile auch zu einer Fülle von Fehlem und 
Designschwächen, von denen Atari-Programmierer Allan Pratt bis heute leider nur einige 
beseitigen konnte. Problemkinder waren und bleiben die Speicherverwaltung und die Ein-/ 
Ausgabeumlenkung. 

Aber auch MS-DOS (zumindest die Version 1.0) war nicht mehr als eine Weiterentwicklung 
vom CP/M für den IBM PC und dazu kompatible Rechner. Und so stimmen noch heute viele 
GEMDOS-Funktionsnummem mit denen der CP/M-Versionen fürZ80-Systeme aus dem Jahr 
1975 überein. Also: obwohl es in vielen Belangen so aussieht wie MS-DOS, istGEMDOS ein 
eigenes Betriebssystem mit vielen Tücken im Detail. Oder, um es mit den Worten von Tim 
Oren zu sagen: “Remember: it looks like a duck, and quacks like a duck, but it’s not a duck!” 
(Professional GEM, Folge 15, “Coping with GEMDOS”). 


Dateisystem 

Dateibezeichnungen 

Eine Dateibezeichnung besteht aus einer optionalen Laufwerksangabe, einer optionalen 
Pfadangabe und dem eigentlichen Dateinamen. Der Dateiname besteht aus einem bis acht 
Zeichen, gegebenenfalls gefolgt von einem Punkt und drei weiteren Zeichen. 
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Erlaubte Zeichen sind: 

A bis Z, a bis z, 0 bis 9, _! @#$% / '& I []{} 

Kleine Buchstaben werden automatisch in Großbuchstaben umgewandelt. Alle anderen Zei¬ 
chen - insbesondere Umlaute - sind nicht erlaubt (auch wenn das AES sie in Datei-Eingabe¬ 
masken erlaubt). 

Der Pfadname besteht aus beliebig vielen Dateinamen, jeweils gefolgt von einem Backslash 
(‘V). Wird am Anfang des Dateinamens ein Backslash eingefügt, beginnt der Pfad im 
Wurzelverzeichnis des Laufwerks, ansonsten wird vom aktuellen Verzeichnis des Laufwerks 
ausgegangen. Fehlt der Pfadname ganz, wird statt dessen das aktuelle Verzeichnis des Lauf¬ 
werks benutzt. 

In Pfadnamen sind zwei besondere Dateinamen erlaubt: 
bezeichnet das aktuelle Verzeichnis 

bezeichnet das eine Ebene über dem aktuellen Verzeichnis liegende Verzeichnis 

Ein Pfad heißt relativ, wenn er nicht mit dem Wurzel verzeichnis beginnt. Anderenfalls spricht 
man von einem absoluten Pfad. 

Vorsicht. Bei Anwendung zu “komplizierter” Pfadbezeichnungen (wie zum Beispiel: 
“. . \.. \. \. . \sybex\. \pbuch\”) scheinen die GEMDOS-intemen Routinen nicht immer 
korrekt zu funktionieren. Im Zweifelsfall sollte man eine eigene Routinen vorschalten, die 
relative in absolute Pfadnamen konvertieren. 

Die Laufwerksbezeichnung besteht aus einem einzelnen Buchstaben zwischen “A” und “Z”, 
gefolgt von einem Doppelpunkt. Fehlt die Laufwerksbezeichnung, wird das aktuelle Laufwerk 
gewählt. 

GEMDOS selbst unterstützt nur 16 verschiedene logische Laufwerke (also “A” bis “P”). 
Durch Installation von Meta-DOS wird die Zahl der Laufwerke auf 26 (also bis “Z”) erweitert. 
Weiche Laufwerke genau verfügbar sind, stellt man am besten mit folgender Konstruktion 
fest: 

Dsetdrv (Dgetdrv()); 

Der Gesamtlänge der Dateibezeichnung setzt GEMDOS selbst keine Grenze. Allerdings hat 
das Desktop eine Begrenzung auf acht Ordnertiefen. Die allermeisten Programme gehen 
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davon aus, daß 128 Zeichen Länge ausreichen. Zusätzlich gibt es spezielle Dateibezeichnungen 
für die zeichenorientierten Geräte, auf die man beispielsweise mittels “FopenO” zugreifen 
kann: 


“CON:”, “con:” 

Bildschirm bzw. Tastatur 

“AUX:”, “aux:” 

Serielle Schnittstelle 

“PRN:’\ “pm:” 

Parallele Schnittstelle 


Das Desktop unterstützt zusätzlich das Laufwerk “c:” (kleingeschrieben) für ROM-Module. 
Dabei handelt es sich allerdings um kein echtes Dateisystem. Weitere Informationen dazu fin¬ 
den Sie bei der Beschreibung der Cartridge-Hardware. 

Schlußbemerkung : Man sollte sich - wann immer möglich - nicht auf das genaue Format von 
Dateinamen verlassen und insgesamt keine Annahmen über 

- das Vorhandensein nicht erlaubter Zeichen, 

- die Unterscheidung zwischen Groß- und Kleinschrift oder 

- die maximale Länge von Dateinamen 

machen. Solche Vorsichtsmaßnahmen erleichtern Portierungen und Anpassungen an neue 
GEMDOS-Versionen wie die Multitasking-Erweiterung “MiNT” bei der zurZeit (Testversion 
0.8) Dateinamen von bis zu 14 Zeichen praktisch beliebiger Art möglich sind (das Dateinamens¬ 
feld in der DTA ist dort nicht zwingend Null-terminiert). 


Aktueller Pfad, aktuelles Laufwerk 

GEMDOS merkt sich zu jedem Laufwerk einen aktuellen Pfad, auf den sich alle Pfadangaben 
stützen, die nicht mit einem ‘ V beginnen. Außerdem gibt es auch ein aktuelles Laufwerk, das 
immer dann benutzt wird, wenn eine Laufwerksangabe fehlt. Zum Setzen und Abfragen gibt 
es “Dgetpath()”, “DsetpathO”, “DgetdrvO” und “Dsetdrv()’\ Die aktuellen Werte werden an 
mittels “PexecQ” gestartete Programme vererbt und dabei gemerkt. 


GEMDOS-Dateisystem 

Das GEMDOS-Dateisystem entspricht weitgehend dem in MS-DOS 2.0benutzten Dateisystem. 
Wenn man beim Formatieren der Disketten einige Punkte beachtet (siehe unter “ProtobtQ”), 
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kann man die Disketten sogar mit einem MS-DOS-Computer austauschen - selbst wenn man 
ein High-Density-Laufwerk benutzt. 

Intern existiert eine klare Arbeitsteilung zwischen BIOS und GEMDOS. Das BIOS stellt 
Routinen zum Lesen und Schreiben (“Rwabs()”), zum Erkennen eines Medienwechsels 
(“Mediach()”) und zur Abfrage von Dateisysteminformationen (“GetbpbO”) zu Verfügung. 

An dieser Stelle sollte man noch erwähnen, daß man sich keineswegs darauf verlassen darf, 
daß GEMDOS tatsächlich das hier geschilderte Dateisystem benutzt. 

Ein Beispiel: Wenn Meta-DOS eingesetzt wird, kann man noch nicht einmal davon ausgehen, 
daß BIOS-Aufrufe zum Lesen und Schreiben benutzt werden. 

GEMDOS benutzt die ersten Sektoren eines Laufwerks für Verwaltungsinformationen. Ein 
Laufwerk besteht typischerweise aus fünf Teilen: dem optionalen Bootsektor, zwei FATs 
(“File Allocation Table”), einem Wurzelverzeichnis und dem Clusterbereich (GEMDOS 
verwaltet die Sektoren in Gruppen mehrerer Sektoren, den Clustern). 

Die FAT beschreibt, welche Cluster belegt sind, und stellt die Verkettung der einzelnen Clu¬ 
ster innerhalb einer Datei her. Alle Dateien und Unterverzeichnisse werden im Clusterbereich 
abgelegt und über die FAT verwaltet. 

Nur das Wurzelverzeichnis stellt in dieser Hinsicht eine Ausnahme dar. 

Beim ersten Zugriff auf ein Laufwerk ruft GEMDOS die Funktion “GetbpbO” auf. 
Zurückgeliefert wird eine BPB-Struktur, aus der alle für GEMDOS interessanten Informatio¬ 
nen extrahiert werden. Dasselbe passiert übrigens auch nach einem Medienwechsel. 


typedef struct 
{ 

WORD recsiz; 
WORD clsiz; 
WORD clsizb; 
WORD rdlen; 
WORD fsiz; 
WORD fatrec; 
WORD datrec; 
WORD numcl; 
WORD bflags; 


/* Bytes pro Sektor */ 

/* Sektoren pro Cluster (Einheit) */ 

/* Bytes pro Cluster */ 

/* Länge des Wurzelverzeichnis in Sektoren */ 
/* Länge des File Allocation Table (FAT) */ 

/* Startsektor der zweiten FAT */ 

/* Sektornummer des ersten freien Clusters */ 
/* Gesamtzahl der Cluster auf dem Medium */ 

/* Bitvektor, zur Zeit nur Bit 0 belegt: 

0 (12-Bit-FAT), 1 (16-Bit-FAT) */ 


} BPB; 
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“recsiz” gibt an, wie groß jeder einzelne Sektor auf dem Medium ist. Mögliche Größen sind 
512, 1024, 2048 und 4096. Bei noch größeren Sektorgrößen kommt es in allen bekannten 
GEMDOS-Versionen zu Problemen mit zu großen Clustergrößen. 

“clsiz” muß laut Atari immer 2 sein. Andere Werte wären zum Lesen mancher MS-DOS- 
Formate wünschenswert, sind aber zur Zeit (GEMDOS 0.19) angeblich nicht möglich (in der 
Praxis scheinen 1-Sektor-Cluster - benötigt für MS-DOS-High-Density-Disketten - zu 
funktionieren). 

“clsizb” ist die Größe eines Clusters in Bytes und somit eigentlich eine überflüssige 
Information (da aus “recsiz” und “clsiz” leicht zu errechnen). 

“rdlen” beschreibt die Länge des Wurzelverzeichnis in Sektoren. Jeder Verzeichniseintrag 
belegt 32 Bytes, somit passen “(rdlen * recsiz) / 32” Einträge in das Verzeichnis. 

Damit ist das Wurzelverzeichnis im Gegensatz zu Unterverzeichnissen in seiner 
Aufnahmefähigkeit durch einen fixen Wert beschränkt (bei “normalen” Disketten liegt diese 
Zahl üblicherweise bei 112 Einträgen). 

“fsiz” beschreibt die Länge jeder einzelnen FAT in Sektoren, “fatrec” gibt die Nummer des 
Anfangssektors der zweiten FAT an. In “datrec” findet man die Sektomummer des ersten 
Clusters, “numd” legt fest, wieviel Cluster auf dem Medium Platz haben. 

“bflags” enthält zusätzliche Informationen über das Dateisystem. Zur Zeit ist nur das unterste 
Bit belegt: wenn es gesetzt ist, hat man es mit 16 Bit großen FAT-Einträgen zu tun (sonst 12 
Bit). NeuereMS-DOS-Versionen erlauben auch 32-Bit-FATS (dort ist die BPB-Struktur auch 
im Hinblick auf das “High Performance File System” von OS/2 um zusätzliche Felder erwei¬ 
tert worden). 

Aus diesen Informationen kann man noch einige weitere Werte berechnen: 

Wenn es Bootsektoren gibt, dann belegen sie die Sektoren 0 bis (fatrec - fsiz --1). Die erste 
FAT beginnt bei (fatrec - fsiz), und das Wurzelverzeichnis startet bei (fatrec + fsiz). 

Verzeichniseinträge 

Ein Verzeichniseintrag kann entweder innerhalb des Wurzelverzeichnisses oder in einem 
Unterverzeichnis auftreten (ein Unterverzeichnis kann als Datei mit Verzeichniseinträgen 
angesehen werden). 

Jeder Eintrag ist insgesamt 32 Bytes lang und hat das folgende Format: 
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typedef struct 


char 

dir narrte [11]; 

/* 

Name inkl. Erweiterung ohne Punkt */ 

BYTE 

dir attr; 

/* 

Attribut */ 

BYTE 

dir_dummy[10]; 

/* 

unbenutzt */ 

DWORD 

dir time; 

/* 

Erstellungszeit */ 

UWORD 

dir_date; 

/* 

Erstellungsdatum */ 

UWORD 

dir stcl; 

/* 

erster Cluster */ 

ULONG 

dir flen; 

/* 

Länge der Datei */ 


} DIR; 

“dir_time”, “dir_date’\ “dir_stcl” und “dir_flen” sind im Intel-Format, das heißt höher- und 
niederwertige Bytes sind vertauscht. Bei gelöschten Dateien ist das erste Zeichen des 
Dateinamens mit dem Wert $E5 überschrieben. 

FAT-Einträge 

In der FAT finden sich Informationen über jeden einzelnen Cluster des Speichermediums. 
Dabei sind folgende Fälle möglich: 

- Der Cluster ist frei. 

Der Cluster ist belegt, und der FAT-Eintrag enthält einen Verweis auf den nächsten 
Cluster der Datei. 

- Der Cluster ist belegt und ist der letzte von der Datei belegte Cluster. 

- Der Cluster ist beschädigt und für weitere Benutzung gesperrt. Viele Programme zum 
Formatieren von Disketten bzw. Partitionieren von Festplatten benutzen diese Möglich¬ 
keit, um als defekt erkannte Sektoren für eine Benutzung zu sperren. 

FAT-Einträge können - je nach Größe des Mediums - jeweils 12 oder 16 Bit groß sein. Unter 
neueren MS-DOS-Versionen werden auch 32-Bit-FATs benutzt, für GEMDOS sind solche 
Formate allerdings nicht ansprechbar. 

Die ersten beiden Einträge der FAT sind unbenutzt, die eigentliche Zählung beginnt also erst 
bei 2. Dies zieht ein Mißverständnis in der Kommunikation zwischen BIOS und GEMDOS 
nach sich, welches dazu führt, daß die beiden letzten Cluster eines Mediums nicht benutzt 
wenden können. GEMDOS-Dateisysteme werden von MS-DOS allerdings nur dann korrekt 
erkannt, wenn sich im ersten Byte jeder FAT eine Kopie des “Mediabytes” (siehe BIOS- 
Einführung) befindet. 
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Die möglichen Werte für die Einträge: 


12-Bit-FAT 

16-Bit-FAT 

Bedeutung 

$000 

$0000 

Freier Cluster 

$001 

$0001 

nicht erlaubt 

$002 - $FEF 

$0002 - $7FFF 

Nummer des nächsten Clusters 


$8000 - $FFEF 

nicht erlaubt 

$FF0 - $FF7 

$FFF0 - $FFF7 

Unbrauchbarer (defekter) Cluster 

$FF8 - $FFF 

$FFF8 - SFFFF 

Letzter Sektor (Dateieende) 


Curiosity killed the FAT... 

Der Satz sagt es schon: Manipulationen am Dateisystem sind eine höchstgradig gefährliche 
Angelegenheit, Allen Programmen, die direkt das Dateisystem manipulieren (zum Beispiel 
Harddisk-”Optimierer”) sollte man mit einer gehörigen Portion Mißtrauen begegnen! 


Dateiattribute 

Die verschiedenen Eigenschaften einer Datei werden über das Attribut-Byte im Verzeichnis¬ 
eintrag festgelegt. Dabei sind folgende Bits definiert (alle weiteren sind für künftige GEM- 
DOS-Versionen reserviert): 


Bit 

Bitmaske 

Bezeichnung 

Erklärung 

0 

0x01 

FAJREADONLY 

Datei ist gegen Überschreiben geschützt 

1 

0x02 

FA_HIDDEN 

Versteckte Datei 

2 

0x04 

FA_SYSTEM 

Systemdatei 

3 

0x08 

FA_VOLUME 

Laufwerksname (Label) 

4 

0x10 

FAjSUBDIR 

Unterverzeichnis 

5 

0x20 

FA_ARCHIVE 

Archiv-Bit 


Schreibgeschützte Dateien können weder gelöscht werden, noch ist es möglich, schreibend 
auf sie zuzugreifen. Versteckte Dateien erscheinen normalerweise nicht im Verzeichnis (die 
GEM-Dateiauswahlbox berücksichtigt dies, das Desktop nicht). Das Attribut “Systemdatei” 
hat seinen Ursprung bei MS-DOS und kann am besten als “darf nicht verschoben werden” 
gedeutet werden. Einen Laufwerksnamen darf es auf jedem Laufwerk nur einmal geben. Wei¬ 
tere Attribut-Bits dürfen nicht gesetzt sein (eine Routine zum Setzen des Laufwerksnamens 
ist unter “Fcreate()” angegeben). 
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FA_VOLUME und FA_SUBDER dürfen niemals in Verbindung mit anderen Attributen 
benutzt werden: in solchen Fällen ist das Verhalten von GEMDOS Undefiniert (zu deutsch: 
es kann funktionieren, aber auch zur Detonation des Monitors führen). 

Das Archiv-Bit wird erst ab GEMDOS 0.15 (Rainbow-TOS) korrekt benutzt: es wird gesetzt, 
wenn eine Datei neu ist oder modifiziert worden ist (allerdings nicht, wenn dabei ihre Länge 
unverändert geblieben ist). Backupprogramme können dieses Bit benutzen, um die veränder¬ 
ten Dateien eines Laufwerks zu finden und zu kopieren. Anschließend sollte es dann mit 
“FattribO” zurückgesetzt werden. Ältere GEMDOS-Versionen haben das Archiv-Bit einfach 
ignoriert. Einige Backup-Programme haben dies ausgenutzt, indem sie das Bit bei archivierten 
Dateien manuell gesetzt haben. 


Medienwechsel (Mediachange) 

Wenn eine Diskette oder eine Wechselplatte (oder eine CD...) gewechselt wird, muß 
GEMDOS natürlich darüber informiert werden. Insbesondere müssen dabei alle dieses Lauf¬ 
werk betreffenden Informationen (Dateien, aktuelle Verzeichnisse, vom GEMDOS gepufferte 
Sektoren) wieder zurückgesetzt werden. 

Intern läuft dabei ein kompliziertes Protokoll zwischen BIOS und GEMDOS ab. Hier ein 
möglicher Verlauf eines Diskettenwechsels: 

1. Der Benutzer entnimmt die Diskette und legt eine andere ein. 

2. GEMDOS versucht, mittels “RwabsO” einen Sektor zu lesen, das BIOS liefert den 
Retum-Wert E_CHNG (-14) zurück. 

3. GEMDOS weiß nun, daß das Medium gewechselt worden ist (oder gewechselt worden 
sein könnte). Deshalb setzt es alle internen Informationen über das Laufwerk zurück und 
ruft “GetbpbO” auf, um sich über den Aufbau des neuen Mediums zu informieren. 

Gleichzeitig wird damit dafür gesorgt, daß das BIOS den Medienwechsel als erkannt 
ansieht und ihn beim nächsten Zugriff nicht mehr meldet. 

In den “Release Notes” zum TOS 1.04 hat Atari eine Beispielroutine abgedruckt, die einen 
solchen Medienwechsel erzwingt. Dies ist für zweierlei Arten von Programmen interessant: 

1. Programme, die unter Umgehung von GEMDOS direkt auf das Dateisystem zugreifen 
und dort Daten verändern (Festplattenpartitionierer, Formatierprogramme, Hilfspro- 
gramme zum Reparieren der Dateisystemstruktur). 
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2. Programme, die aus irgendwelchen Gründen dazu gezwungen sind, direkt “GetbpbQ” 
aufzurufen: ansonsten könnte es passieren, daß ein etwaiger Medienwechsel nicht an 
GEMDOS gemeldet wird und dadurch Informationen auf dem Medium zerstört werden 
(beispielsweise dadurch, daß noch Sektoren vom “vorherigen” Medium gepuffert sind). 

Ein Nachteil sollte allerdings nicht verschwiegen werden: Durch den Medienwechsel gehen 
alle Informationen über das betreifende Laufwerk verloren; dazu gehören unter anderem die 
aktuellen Verzeichnisse und offene Dateien. 

Daher sollte man diese Möglichkeit nur dann benutzen, wenn es wirklich nicht anders geht 
und die Effekte für den Anwender verständlich sind: wie zum Beispiel im Desktop beim 
Drücken der ESC-Taste oder innerhalb eines Festplattenpartitionierers nach dem Löschen 
einer gesamten Partition. 

Nun zu der Beispielroutine: Sie basiert auf dem Verbiegen der entsprechenden BIOS-Funk- 
tionen auf eigene Routinen, die einen Medienwechsel vorspiegeln. Anschließend wird eine 
Datei auf dem betreffenden Laufwerk geöffnet und in der Getbpb-Routine dafür gesorgt, daß 
alle verbogenen Vektoren wieder zurückgesetzt werden (dazu wird das im Anhang beschrie¬ 
bene XBRA-Verfahren benutzt). 

; Erzwingen eines Media-Change 

; basiert auf der in den "Raihbow TOS Release Notes" vom 
; 7. 8. 89 angegebenen Routine 

; Binding für TC: extern int cdecl raediach (int drive); 

; liefert 1 zurück, wenn GEMDOS nicht Getbpb aufgerufen 
; hat (Fehler!), sonst 0 (OK) 

.globl mediach 

mediach: 

move.w 4(sp),d0 
movem.l dl-a6,-(sp) 

move.w dO,mydev 
add.b #"A",dO 
move.b dü,fspec 

loop: 

clr.l -(sp) 
move.w #$20, -(sp) 


; Laufwerksnummer 
; Register retten 


; in Dateinamen eintragen 

; Supervisor-Modus 
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trap 

#1 

addq 

#6, sp 

move.1 

dO, -(sp) 

move.w 

#$20,-(sp) ; 2. Aufruf vorbereiten 

; alte Vektoren retten 

move.1 

$472,oldgetbpb 

move.1 

$47e,oldmediach 

move.1 

$476,oldrwabs 

move.1 

#newgetbpb,$472 

move.1 

fnewmediach, $47e 

move.1 

#newrwabs ,$476 

; Datei 

auf dem Laufwerk öffnen 

clr .w 

-(sp) 

move.1 

#fspec,-(sp) 

move.w 

#$3d, -(sp) 

trap 

#1 

addq 

#8, sp 

; Datei 

wieder schließen 

tst. 1 

dO 

bmi 

noclose 

move.w 

dO,-(sp) 

move.w 

#$3e,- (sp) 

trap 

#1 

addq 

#4, sp 

noclose: 

moveq 

#0,d7 ; Return-Wert OK 

cmp. 1 

#newgetbpb,$472 

bne 

done ; Routine verschwunden? 

moveq 

#l,d7 ; sonst ERROR 

move.1 

oldgetbpb,$472 

move.1 

oldmediach, $47e 

move.1 

oldrwabs,$476 
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done: 

trap #1 ; User-Modus 

addq #6,sp 

move.1 d7,dO 
movem.1 (sp)+, dl-a6 
rts 

; newgetbpb: wenn es das richtige Laufwerk ist: Vektoren 
; wieder aushängen. Auf jeden Fall aber die bisherige 
; Routine aufrufen 

.dc.b "XBRAMDCH" 
oldgetbpb: 

.dc.l 1 

newgetbpb: 

move.w mydev,dO ; richtiges Laufwerk? 
cmp.w 4(sp),d0 
bne dooldg 

; Vektoren entfernen 
move.l oldgetbpb,$472 
move.1 oldmediach,$47e 
move.1 oldrwabs,$476 

dooldg: 

move.1 oldgetbpb,aO 
jmp (aO) 

; newmediach: wenn es das richtige Laufwerk ist: 2 
; zurückliefern, ansonsten die bisherige Routine 
; aufrufen 

.dc.b "XBRAMDCH" 
oldmediach: 

.dc.l 1 

newmediach: 

move.w mydev,dO ; richtiges Laufwerk? 
cmp.w 4(sp) ,dO 
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bne dooldm 

moveq.l #2,d0 ; bestimmt gewechselt! 

rts 

dooldm: 

move.1 oldmediach,aO 
jmp (aO) 

; newrwabs: E_CHNG (-14) zurückliefern, wenn es 
; das richtige Laufwerk ist 

.dc.b "XBRAMDCH" 
oldrwabs: 

. de. 1 1 

newrwabs: 

move.w mydev,dO 

emp.w 14(sp),d0 ; Laufwerksnummer? 

bne dooldr 

moveq.l #-14,dO 
rts 

dooldr: 

move.1 oldrwabs, aO 
jmp (aO) 

.data 

fspec: 

.dc.b "X:\X",0 
.bss 

mydev: 

.ds.w 1 

.end 

GEMDOS-Puffer 

GEMDOS verfügt über eine einfache Pufferverwaltung für einmal gelesene Sektoren. In 
GEMDOS-Version 0.13 (also vor TOS 1.04) wurden diese Puffer allerdings nur sehr ineffektiv 
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benutzt (zum Beispiel wurden die Pufferinhalte schon beim Schließen einer Datei “verges¬ 
sen”). Intern werden die Puffer in zwei Listen einfach verzeigerter Pufferkontrollblöcke 
verwaltet. Jeder dieser BCBs (“Buffer-Control Block”) sieht folgendermaßen aus: 


typedef struct _bcb 
{ 


struct _bcb 
WORD 
WORD 
void 
} BCB; 


*b_link; /* Zeiger auf den nächsten BCB */ 
b_negl; /* auf -1 initialisieren */ 
b_private[5]; 

*b_buf; /* Zeiger auf eigentlichen Puffer */ 


GEMDOS verwaltet zwei getrennte Listen: eine für die FAT und das Wurzelverzeichnis, die 
zweite für den Rest der Sektoren (also exakt diejenigen, die mit Hilfe der ersten Liste verwaltet 
werden). 

Normalerweise wird bei der Systeminitialisierung nur für je zwei Sektoren Platz angelegt. 
Eine Erweiterung der Puffer führt daher zu einer deutlichen Beschleunigung der GEMDOS- 
Dateifunktionen. 


Seit AHDI/HDX 3.0 dürfen Sektoren auch größer als 512 Bytes werden (läßt sich mit der 
BIOS-Funktion “GetbpbO” abffagen). Beim Hinzufügen von Puffern muß man also wissen, 
wie groß ein Sektor maximal werden kann. Da es auch wechselbare Medien (Disketten oder 
Wechselplatten) gibt, ist diese Frage gar nicht so leicht zu beantworten. AHDI 3.0 stellt diese 
Information in der “pun_ptr”-Struktur (siehe System variablen) zur Verfügung, und jeder Fest¬ 
plattentreiber, der dazu kompatibel sein will, sollte tunlichst genauso verfahren. 

Auch wenn es schon genug andere Gründe gibt, den französischen GEMDOS-Ersatz 
“TurboDos” (GEMDOS 0.14) nicht zu benutzen: “TurboDos” ist nicht dazu in der Lage, Sek¬ 
toren von mehr als 512 Bytes Größe zu verwalten. 

Die einfachste Methode zur Erweiterung der Pufferliste ist, das von Atari dafür vorgesehene 
Programm “CACHENNN.PRG” zu benutzen. Man findet es auf den Systemdisketten zu 
Atari-Festplatten oder auch (hoffentlich) beim Atari-Fachhändler. 

Viele andere Festplattentreiber haben diese Funktion bereits fest eingebaut - so zum Beispiel 
HUSHI/SCSI-Tool von den Autoren dieses Buchs. 

Um selbst neue Puffer hinzuzufügen, muß man also erst einmal die maximal benötigte Sektor¬ 
größe kennen. Dazu konsultiert man die vom Festplattentreiber installierte PUN_INFO-Struk- 
tur: 
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typedef struct 

{ 

WORD puns; 

BYTE pun[16]; 

LONG part_start[16]; 

LONG P_cookie; 

LONG *P_cookptr; 

UWORD P__version; 

UWORD P__max_sector; 

LONG re served[16]; 

} PUN_INFO; 

PUN_INFO *getpun (void) 

{ 

PUN_INFO *P; 

LONG oldstack; 
oldstack = Super (OL); 

P = * ( (PÜN__INFO **) (0x516L) ) ; 

Super ((void *)oldstack); 

if (P) /* überhaupt gesetzt? */ 

if (P->P_cookie = 0x41484449L) /* Cookie gesetzt? */ 
if (P->P_cookptr == & (P->P_cookie)) 
if (P->P_version >= 0x300) 
return P; 

return OL; 

} 

WORD getsize (void) 

{ 

PUN__INFO *P = getpun () ; 
if (P) 

return P->P_max_sector; 

else 

return 512; 

} 

Wie installiert man nun einen neuen Puffer? 


1. Genügend Speicher für einen Sektor (also “getsizeO” benutzen) allozieren. 
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2. Speicher für einen BCB allozieren. 

3. Das “b_negl”-Feld des BCBs auf -1 setzen. 

4. Das “b_bufr”-Feld des BCBs mit einem Zeiger auf den Sektorpuffer füllen. 

5. Je nachdem, an welche Liste der Puffer angefügt werden soll: das “b_link”-Feld auf den 
bisherigen Inhalt von $4B2 bzw. $4B6 setzen und die Adresse des “neuen” BCBs in $4B2 
bzw. $4B6 eintragen. 

Das Ganze wird für jeden weiteren Puffer wiederholt. 

Das Programm darf natürlich nicht normal terminieren, sondern muß mit “PtermresO” resi¬ 
dent installiert werden. 


Kanäle 

Dateikennungen 

Alle Dateien und Geräte werden über sogenannte Handles (Kennungen) angesprochen, bei 
denen es sich um 16-Bit-Zahlen handelt (sonst könnte man sie nicht von den 32-Bit-Retum- 
Codes der Dateifunktionen unterscheiden). 

Insgesamt gibt es drei verschiedene Klassen von Handles: 

- Die drei zeichenorientierten Kanäle “CON:”, “AUX:” und “PRN:” mit den Handles -1, 
-2 und -3. Diese Kanäle geben quasi direkt auf den dazugehörigen BIOS-Funktionen 
aus. 

— Die sogenannten Standardkanäle, die man mittels “FforceO” auch umlenken kann: 

stdin (0) Standardeingabe 

stdout (1) Standardausgabe 

stdaux (2) serielle Schnittstelle 

stdpm (3) parallele Schnittstelle 

Zusätzlich gibt es noch die Standardhandles 4 und 5, die allerdings zur Zeit von GEM¬ 
DOS nicht benutzt werden. 


die Dateihandles (ab Handle 6 aufwärts). 
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Ein-/Ausgabeumlenkung 

Während die zeichenorientierten Kanäle direktmit dem BIOS und dieeigentlichen Dateihandles 
direkt mit irgendwelchen geöffneten Dateien verbunden sind, muß man sich unter den 
Standardkanälen eher Platzhalter vorstellen. 

Normalerweise sind die Standardkanäle folgendermaßen belegt: 


Name 

Nummer 

normalerweise verbunden mit 

stdin 

0 

CON: (-1) 

stdout 

1 

CON: (-1) 

stdaux 

2 

AUX: (-2) 

stdpm 

3 

PRN: (-3) 


Die Belegung der Kanäle 4 und 5 ist nicht definiert. 

Die Funktion “Fforce()” erlaubt es, einem Standardkanal ein neues Ziel zu geben. Mit 
Fforce (1, -2) ; 

könnte man beispielsweise alle Bildschirmausgaben auf die serielle Schnittstelle umlenken. 

“FdupO” macht Kopien von Dateihandles. Meistens wird es benutzt, um nach erfolgter Um¬ 
lenkung die alte Zuordnung der Standardkanäle wiederherstellen zu können. Das kann zum 
Beispiel so aussehen: 

WORD handle, dup; 

handle = Fcreate ("TMPFILE", 0); 

dup = Fdup (1); /* Kopie von stdout */ 

Fforce (1, handle); /* umlenken */ 

/* ... Kommandos bei umgelenkter Standardausgabe ausführen */ 
Fclose (handle); 

Fforce (1, dup); /* Umlenkung rückgängig */ 


Das ist leider nur die Theorie. In der Praxis ist die Ein-/Ausgabeumlekung unter GEMDOS 
(zumindest bis einschließlich GEMDOS 0.19) mit erheblichen Fehlem behaftet: 
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- Wenn man “FdupQ” anwendet und dann mittels “Pexec()” ein Programm startet, kann 
es zum Verlust von Handles und zur Zerstörung GEMDOS-intemer Strukturen kommen 
(Problem: GEMDOS kommt praktisch gar nicht mit mehrfach von verschiedenen 
Prozessen geöffneten Dateien zurecht). 

- Vor GEMDOS 0.15 funktionierten weder Umlenkung auf den Drucker noch die 
Umlenkung aller Funktionen zur Zeichenausgabe (“C....”). 

Ein-/Ausgabeumlenkung in Shells 

Vielleicht das wichtigste Merkmal eines “reinrassigen” Tools in Kommandoshells ist die 
Beschränkung auf die Zeichenkanäle “stdin” und “stdout”. In der C-Standardbibliothek 
bezeichnet man damit die “Dateien”, die (mehr oder weniger) fest mit dem Bildschirm für Ein- 
und Ausgabe verbunden sind. Auf GEMDOS-Ebene handelt es sich um die Standardkanäle 
0 (stdin) und 1 (stdout), die man mit allen GEMDOS-Funktionen direkt benutzen kann, ohne 
sie erst öffnen zu müssen. Auch die GEMDOS-Standardfunktionen wie “CconoutO” oder 
“CconrsO” benutzen immer Kanal 0 und 1. 

Das Schöne an den GEMDOS-Standardkanälen ist, daß man sie “umlenken” kann. Ein 
Beispiel: wenn das Archivierungsprogramm ARC ein Inhaltsverzeichnis ausgibt, benutzt es 
den GEMDOS-Kanal “stdout” (Kanal 1). In den meisten Shells kann man nun die Ausgabe 
von “stdout” umlenken. Das sieht dann beispielsweise so aus: 

ARC V TEST.ARC >FILELIST 

Die Shell sieht dann das Kommando “>FILELIST” und wertet dies als Aufforderung, auf 
“stdout” vorgenommene Ausgaben in die Datei “FILELIST” zu schreiben. Also wird diese 
Datei angelegt, und der Kanal “stdout” mittels der GEMDOS-Funktion “Fforce()” umgeleitet. 
Dabei sind auch Variationen möglich: 

- Außer einem Dateinamen kann man auch jede Dateibezeichnung angeben, die GEMDOS 
bei “Fopen()” versteht, beispielsweise also “AUX:” (für die serielle Schnittstelle) oder 
“PRN:” (für die parallele Schnittstelle). 

- Ein doppeltes Größerzeichen wird normalerweise so verstanden, daß die angegebene 
Datei nicht neu angelegt wird, sondern daß die Daten hinten an die bestehende Datei 
angehängt werden sollen. 

Was für “stdout” gilt, stimmt auch für “stdin”. Der Komprimierer ZOO kennt zum Beispiel 
einen Modus, bei dem die Namen der zu komprimierenden Dateien von “stdin” eingelesen 
werden. 
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Man könnte damit beispielsweise mit einem Editor eine Textdatei FELES.TXT mit den Namen 
der zu komprimierenden Dateien anlegen und dann mittels 

ZOO al ZOOFILE.ZOO CFILES.TXT 

von ZOO verarbeiten lassen. Hier wird also ganz analog das Kleinerzeichen als Symbol für 
die Eingabeumlenkung benutzt. 

Unter UNIX gibt es nun eine ganze Reihe von Standardprogrammen, die einfach nur Zeichen 
von “stdin” lesen, irgendwie verarbeiten und dann auf “stdout” ausgeben. So ein Programm 
nennt man dann “Filter”. Viele Programme machen dies davon abhängig, ob man sie mit oder 
ohne Parameter aufruft. 

Besonders praktisch sind solche Programme, wenn man eine Shell besitzt, die sogenannte 
“Pipes” erlaubt. Durch eine Pipe kann man die Standardausgabe eines Programms mit der 
Standardeingabe eines zweiten Programms verbinden. Bei einem Multitasking-Betriebsystem 
laufen die einzelnen Programme dann sogar tatsächlich gleichzeitig ab. 

Und wieder ein Beispiel: 

ls I zoo al zoofile 

Der senkrechte Balken ist das sogenannte Pipe-Symbol, wie es jede UNIX- und UNIX-artige 
Shell versteht. Die Ausgabe des ersten Kommandos (ls) wird direkt als Eingabe für ZOO 
benutzt. 

Echte Pipes sind unter GEMDOS natürlich nicht möglich. MitHilfe der Ein-/Ausgabeumlenkung 
über eine temporäre Datei kann man allerdings ein ähnliches Ergebnis erzielen: 

ls >TEMPFILE 
zoo al CTEMPFILE 

Pipes können selbstverständlich auch mehr als zwei Stufen haben. Das Schöne an diesen 
Mechanismen: solange die Programme nur sauber über “stdin” und “stdout” operieren, 
brauchen Sie selbst nichts darüber zu wissen: die Hauptarbeit liegt bei der Shell. 

Ein Konzept für stderr 

Ganz problemlos ist dies allerdings nicht; nehmen wir mal den folgenden Fall: 


ÄRC V ARCHIV.ARC >OUtput 
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Mal angenommen, die Archivdatei ARCHIV.ARC ist gar nicht vorhanden: Wie soll dann 
ARC dem Benutzer mitteilen, daß ein Fehler vorliegt? Die einfache Lösung unter UNIX: 
zusätzlich zum Standardausgabekanal “stdout” gibt es den Standard-Fehler-Kanal “stderr”, 
auf dem man Fehler und Warnungen ausgeben kann. Die wichtigsten Eigenschaften von 
“stderr”: 

- “stderr” ist normalerweise mit dem Bildschirm verbunden. 

- Ein technisches Detail: bei Verwendung der C-Standardbibliothek ist “stderr” immer 
ungepuffert (während “stdin” und “stdout” zeilenweise gepuffert arbeiten). 

- Unter UNIX ist “stderr” Standardkanal 2; die Umlenkung in der Shell läuft mittels “2>” 
bzw. “2<“. 

Ein besonderer Leckerbissen: wie eben schon angedeutet, kann man von “stderr” auch Zei¬ 
chen lesen. Wozu man das nun wieder braucht? Das Standardtool “more” liest beispielsweise 
Zeilen von “stdin” und bietet diese seitenweise (zum Blättern) an. Nur: woher soll “more” sei¬ 
ne Tastendrücke bekommen, wenn “stdin” schon mit einer Datei verbunden ist? Die einzige 
Möglichkeit ist, auch das Lesen von “stderr” zu erlauben! 

Kommen wir zu dem unvermeidlichen (?) Haken an der Sache: Leider hat Atari im GEMDOS 
keinen Standardfehlerkanal vorgesehen. Die Hersteller der C-Compiler haben deshalb ver¬ 
schiedene Methoden ersonnen, um einen Ersatz anzubieten. 

Da gäbe es zunächst die Compiler, die “stderr” und “stdout” einfach auf den gleichen Kanal 
lenken, womit natürlich fast alle Vorteile zunichte gemacht werden. Nicht zur Übernahme 
empfohlen. 

Eine zweite Möglichkeit ist, “stderr” fest mit dem Bildschirm zu verbinden (über GEMDOS- 
Kanal -1). Damit sind zwar “stdout” und “stderr” voneinander getrennt, aber “stderr” kann 
dadurch nicht mehr umgelenkt werden. Ferner gehen viele UNIX-Programme, die man gerne 
portieren möchte (z. B. “compress”), davon aus, daß “stderr” Kanal 2 ist. Diese Lösung wird 
meines Wissens von der Turbo-C-Library benutzt. Elegant, aber nicht ganz problemlos! 

Die offensichtliche Lösung ist, für “stderr” wie unter UNIX Standardkanal 2 zu benutzen. 
Kanal 2 wird von GEMDOS normalerweise für die serielle Schnittstelle benutzt. 

Allerdings hat Atari bereits 1986 im “GEMDOS Reference Manual” daraufhingewiesen, daß 
man besser direkt über das BIOS auf die serielle Schnittstelle zugreifen sollte. Ansonsten kann 
man auch einen der “freien” Standardkanäle benutzen (nachdem man ihn mit “FforceO” auf 
die serielle Schnittstelle umgelenkt hat). 
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Alle zum Mark-Williams-C-Compiler gehörigen Tools und auch die von diesem Compiler 
erzeugten Programme nutzen für “stderr” Kanal 2. 

Der Nachteil: normalerweise ist Kanal 2 eben mit der seriellen Schnittstelle verbunden - nur 
wenn man in seiner Shell Kanal 2 auf den Bildschirm umlenkt, bekommt man eventuelle 
Fehlermeldungen zu Gesicht (davon sind auch die meisten GNU-Programme betroffen). 

Nichtsdestotrotz gibt es keine bessere Alternative. Atari-Programmierer Allan Pratt machte 
daher folgenden Vorschlag: beim Start sollte jedes Programm testen, ob Kanal 2 bereits auf 
eine Datei umgelenkt ist. Dazu kann man die Funktion “isattyO” (wie in der GEMDOS- 
Funktionsübersicht beschrieben) verwenden. 

Wenn dem nicht so ist, sollte man mittels “Fforce (2, -1)” die Ausgabe auf den Bildschirm 
umlenken. 

Damit sind schon mal ein paar Probleme gelöst. Startet man ein solches Programm vom 
Desktop oder von einer “unwissenden” Shell, dann wird die Ausgabe von “stderr” auf den 
Bildschirm umgelenkt. 

Hat man eine intelligente Shell, und möchte man “stderr” in eine Datei umlenken, dann geht 
das auch. 

Ein kleiner Haken bleibt jedoch. Ein Kommando wie 

ÄRC X TESTFILE 2>PRN: 

also: “Bitte gib Deine Fehlermeldungen auf dem Drucker aus” wird nicht richtig verstanden. 

Aber auch dieses Problem läßt sich leicht aus der Welt schaffen. In jeder “guten” Shell kann 
man Environmentvariablen setzen. 

Wenn der Startupcode das Vorhandensein der Environmentvariablen “STDERR” als Auffor¬ 
derung wertet, Kanal 2 einfach dort zu lassen, wo er ist, sind alle Probleme beseitigt. 

Das Schöne an dieser Methode im Überblick: 

1. “stderr” verhält sich hier praktisch genauso wie unter UNIX. 

2. Mit einer guten Shell kann man mit “stderr” alles machen, was man sich wünschen kann. 

3. Diese Methode kollidiert nicht mit alten Programmen und benötigt ausschließlich 
vorhandene und funktionierende Funktionen des GEMDOS. 
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Speicherverwaltung 


Einleitung 

GEMDOS verwaltet den Speicher mittels zweier verketteter Listen (je eine für freie und eine 
für belegte Speicherblöcke). In den existierenden GEMDOS-Versionen wird diese Liste 
allerdings in einem statischen Speicherbereich geführt, so daß es eine feste Grenze für die 
maximale Zahl von freien und belegten Speicherblöcken gibt (mehr dazu bei der Erklärung 
des “GEMDOS-Pools”). Für jeden belegten Block wird vermerkt, welcher Prozeß ihn alloziert 
hat. Damit hat GEMDOS die Möglichkeit, bei Programmende alle angeforderten Speicher¬ 
bereiche freizugeben. 

Zur Suche nach freien Speicherblöcken benutzt GEMDOS ein “rotating first-fit”-Verfahren. 
Dabei bedeutet “first-fit”, daß GEMDOS immer den ersten ausreichend großen Block nimmt 
(und nicht etwa denjenigen, dessen Größe der angeforderten am nächsten kommt), “rotating” 
steht dafür, daß GEMDOS diese Suche nicht immer am Anfang, sondern bei der letzten 
Fundstelle beginnt. 

Die GEMDOS-Speicherverwaltung ist speziell für relativ wenige, große Speicherblöcke 
geeignet. Wer in seinem Programm viele, kleine Blöcke braucht, sollte den Speicher in 
größeren Mengen anfordem und dann selbst verwalten (wie es die meisten C-Bibliotheken bei 
“mallocO” machen). Dies ist übrigens kein GEMDOS-eigenes Problem - andere Betriebs¬ 
systeme wie UNIX funktionieren genauso. 

Weitere Hinweise zur Speicherverwaltung finden sich bei der Erklärung der GEMDOS- 
Funktion “MallocO”. Eine Regel ist allerdings so wichtig, daß sie hier nochmals wiederholt 
wird: “Du sollst nicht auf Speicherbereiche zugreifen, die Dir nicht gehören!” 


Der GEMDOS-Pool 

Vorsicht! In diesem Abschnitt geht es um höchst komplexe Vorgänge tief im Innern des 
GEMDOS, für die man sich eigentlich gar nicht interessieren müßte - wäre da nicht eine beein¬ 
druckende Zahl von Fehlem, Patchprogrammen, Relikten aus alter Zeit und anderen gräß¬ 
lichen Dingen im Spiel. 

Eine der Aufgaben von GEMDOS ist die Verwaltung des Systemspeichers. Daraus ergibt sich 
natürlich eine Einschränkung für die Möglichkeiten, die GEMDOS selbst hat: anders als die 
höherliegenden Betriebssystemschichten AES und VDI kann GEMDOS eben keine Aufrufe 
von “MallocO” tätigen. 
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Nun hat GEMDOS leider eine Menge von Aufgaben zu erledigen, die dynamischer Natur sind. 
Dazu gehört nicht nur die Verwaltung freier und belegter Speicherblöcke, sondern auch die 
Buchführung über offene Dateien oder aktuelle Verzeichnisse. Dabei sollte man nicht 
vergessen, daß jeder GEMDOS-Prozeß für jedes GEMDOS-Laufwerk ein aktuelles Verzeich¬ 
nis kennt. 

Zur Unterbringung solcher Informationen verfügt GEMDOS über den “GEMDOS Pool”, der 
(wen wundert’s?) eine fixe Größe hat und bei Bedarf nicht automatisch vergrößert werden 
kann. 

Wer schon mal eine Speicherverwaltung programmiert hat, wird nun zu Recht ein wenden, daß 
man zumindest für eine ganz normale Implementation von “MallocO” gar keinen eigenen 
Speicher braucht. Schließlich müssen ja nur Listen von freien und belegten Blöcken geführt 
werden, und dazu könnte man eigentlich problemlos jeweils die ersten Bytes eines Blocks 
mißbrauchen (dieses einfache Verfahren wurde auch von Kemighan und Ritchie, den 
Schöpfern der Sprache C, publiziert). 

Leider legt GEMDOS seine Informationen im Pool ab, und so ist schon von daher die maxima¬ 
le Anzahl von durch “MallocO” allozierten Speicherblöcken durch die Größe des Pools be¬ 
schränkt. Warum Atari das noch nicht geändert hat? Viele Programme verlassen sich darauf, 
daß nacheinander allozierte Speicherblöcke auch an aufeinanderliegenden Adressen liegen - 
was natürlich nicht nur gar nicht immer der Fall ist, sondern natürlich auch nie dokumentiert 
war. Daher zur Zeit diese Rücksichtnahme auf fehlerhafte Programme von gestern, die Atari 
hoffentlich bei der nächsten größeren Überarbeitung von GEMDOS aufgeben wird. 

Zurück zur Belegung des Pools: Jedes “aktive” Verzeichnis belegt zwei Einträge. Ein Ver¬ 
zeichnis ist aktiv, wenn es ein aktuelles Verzeichnis oder ein Wurzelverzeichnis ist oder wenn 
es eine offene Datei oder ein aktives Unterverzeichnis enthält. Wenn man eine Datei öffnet, 
die innerhalb einer zehnfach verschachtelten Ordnerhierarchie steckt, sind dadurch insgesamt 
zehn Verzeichnisse aktiv. 

Zu beachten ist dabei, daß jedes Verzeichnis nur einmal im Pool auftaucht, egal aus wie vielen 
Gründen es offen ist. Zusätzlich braucht jede offene Datei einen Eintrag und jeder freie oder 
belegte Speicherblock 1/4 eines Eintrags. 

Der “40-Ordner-Fehler” 

Alte GEMDOS-Versionen (vor 0.15 im TOS 1.04) hatten nun ein großes Problem: War ein 
Verzeichnis einmal aktiv geworden, dann wurde der entsprechende Eintrag nie wieder aus 
dem GEMDOS-Pool entfernt. Und so konnte man im TOS 1.00 maximal 40 Ordner öffnen. 
Im TOS 1.02 (Blitter-TOS) entschärfte man das Problem, indem man die Größe des Pools 
vergrößerte (und damit natürlich den freien Speicherplatz verminderte). 
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Wie äußerte sich nun das Problem? Einmal konnte es bei Aufrufen von “MallocO” zu 
Fehlermeldungen kommen, obwohl eigentlich noch Speicher vorhanden gewesen wäre. Der 
andere Effekt war, daß geöffnete Verzeichnisse scheinbar leer waren, weil einfach nicht genug 
Speicher zum Verwalten der Verzeichnisinformationen da war. 

Was ist nun bei Atari unternommen worden? 

Zunächst führte man ab TOS 1.02 einen Zeiger im ROM-Header (siehe “_sysbase”) ein, über 
den diese Liste nachträglich erweitert werden kann. Dieser Zeiger (oder die fixe Adresse im 
TOS 1.00) wird vom Programm “FOLDRIOO.PRG” benutzt, um den GEMDOS-Pool zu 
erweitern. Für “100” kann eine beliebige Zahl eingesetzt werden - “FOLDRIOO.PRG” 
erweitert den GEMDOS-Pool um 200 Einträge zur Aufnahme von 100 aktiven Verzeichnis¬ 
sen. “FOLDRIOO.PRG” befindet sich auf der Systemdiskette zu Atari-Festplatten, in prak¬ 
tisch allen Mailboxen und sollte auch bei jedem Atari-Händler zu bekommen sein. Viele 
Harddisktreiber (“AHDI”, “HUSHI” und andere) sorgen bereits selbsttätig für eine Auf¬ 
stockung des Pools. 

In GEMDOS 0.15 (TOS 1.04) hat Atari viel verbessert. Der Pool hat noch immer eine feste 
Größe, wird aber erheblich besser genutzt. Insbesondere werden Einträge von nicht mehr 
aktiven Verzeichnissen wieder freigegeben, und auch die Wiederverwendung freigewordener 
Einträge ist geschickter geregelt. Konsequenterweise hat man den GEMDOS-Pool auch 
wieder auf die ursprüngliche Länge zurückgestutzt. 

Durch das Öffnen vieler Verzeichnisse kann man nun eigentlich nicht mehr in Bedrängnis 
kommen, wohl aber durch allzu viele “Malloc()”-Aufrufe. Es kann also immer noch Vorkom¬ 
men, daß man bei “MallocO” eine Fehlermeldung erhält, obwohl eigentlich noch Speicher da 
wäre. Statt dessen sollte man natürlich eine Laufzeitbibliothek benutzen, die den Speicher in 
Stücken von mindestens 16 Kilobyte per “MallocO” anfordert und dann die Verwaltung selbst 
erledigt (alle mir bekannten C-B ibliotheken funktionieren so). Immerhin erhält man eine sinn¬ 
volle Fehlermeldung, die man eben nur richtig interpretieren muß. 

Das Problem der aktiven Verzeichnisse wird durch die verbesserten Algorithmen bereits stark 
gelindert. Wenn tatsächlich trotzdem mal der GEMDOS-Pool überläuft, bekommt man eine 
Fehlermeldung auf den Bildschirm, und das System steht: 

*** OUT OF INTERNAL MEMORY: 

*** USE FOLDRIOO.PRG TO GET MORE. 

*** SYSTEM HALTED *** 

Das ist zwar nicht schön, aber besser als ein Weiterarbeiten meinem Undefinierten Systemzustand. 
Der Tip, “FOLDR100” zu benutzen, ist allerdings kaum hilfreich: nach menschlichem Ermes- 
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sen kann das Problem im normalen Betrieb gar nicht auftreten (es sei denn, man versucht tat¬ 
sächlich, viele sehr tief geschachtelte Dateien zu öffnen). Der Grund ist mit sehr hoher Wahr¬ 
scheinlichkeit eine Zerstörung interner GEMDOS-Variablen durch ein fehlerhaftes Pro¬ 
gramm. 

Ein solcher Übeltäter war pikanterweise GEMDOS selbst (in der Version 0.15, die man in TOS 
1.04 und TOS 1.06 findet). Lange Rede, kurzer Sinn: bei diesen TOS-Versionen sollte man 
das Programm “POOLFIX3.PRG” im AUTO-Ordner haben (Bezugsquelle: Systemdiskette, 
Mailboxen, Atari-Händler). 

Wenn man dennoch die Fehlermeldung zu sehen bekommt, dann liegt das meist daran, daß 
GEMDOS abgrundtief verwirrt ist. Selbst unter GEMDOS 0.19 kann man solche Effekte in 
Abhängigkeit mit der (nicht vollständig korrekt funktionierenden) Ein-/Ausgabeumlenkung 
provozieren. 


Alternate RAM 

Bei der Entwicklung der TT-Reihe stand Atari vor einem großen Problem: Wie kompatibel 
sollte die Hardware der neuen Rechnern zu den “alten” ST-Modellen sein? Erste Prototypen 
von 68020-Systemen, die auf Ebene der Hardware nicht vollständig kompatibel waren, wur¬ 
den deshalb nie zur Marktreife entwickelt. 

Hauptproblem waren die vielen Programme, die aus verschiedenen Gründen direkt 
Hardwarebausteine des ST ansteuem. In manchen Fällen hatten die Programmierer keine 
andere Wahl (Gerätetreiber), in vielen Fällen jedoch war es einfach die mangelnde Voraus¬ 
sicht der Programmierer. 

So entschloß sich Atari, im TT praktisch sämtliche Bausteine des ursprünglichen ST beizu¬ 
behalten: eine Entscheidung, die nicht nur die Fertigstellung massiv verzögert, sondern auch 
mit Sicherheit die Kosten des Rechners unnötig erhöht hat. 

Nun war der ST eigentlich ein 24-Bit-System, und die “alte” Architektur ist nicht in der Lage, 
mit den 32 Bit großen Speicheradressen des TT zurechtzukommen. 

Daher verpaßte man dem TT zwei verschiedene Arten von Speicher: das ST-RAM (das immer 
im 24-Bit-Adreßbereich, also in den ersten 16 MByte liegt) und das restliche RAM - das 
“Altemate RAM”. 

Als Faustregel gilt: Die “alte” ST-kompatible Hardware kann ausschließlich auf Adressen im 
ST-RAM zugreifen. 
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Dazu gehören: 

- der Videochip. Daher darf man “Setsereen()’’ nur für Adressen im ST-RAM benutzen. 
Das Ganze stellt aber kein ernsthaftes Problem dar, weil “ordentliche” Grafikprogramme 
sowieso nur ausschließlich über VDI und AES ausgeben dürfen. 

- der DMA-Soundchip: für diesen Soundchip (im STE und TT) gibt es bislang leider keine 
Softwareunterstützung durch das Betriebssystem. 

- ACSI-DMA: der Direktzugriff auf Festplatten am ACSI-Port sollte sowieso den dafür 
spezialisierten Treibern überlassen bleiben. Die Laserdrucker der SLM-Reihe sollten 
ausschließlich via VDI oder Diablo-Treiber angesteuert werden. 

- .. .und schließlich darf man selbstverständlich nicht davon ausgehen, daß - wie auf einem 
68000er-System - die obersten acht Bits einer Adresse unbenutzt sind und anderweitig 
benutzt werden können. 

Sämtliches RAM, das nicht ST-kompatibel ist, heißt “Altemate” (also “anderes”) RAM. Wei¬ 
tere Informationen hat man nicht. Im TT kann “Altemate RAM” sowohl das schnelle TT- 
RAM (auf das man per SCSI-DMA zugreifen kann) als auch ganz besonders langsames RAM 
auf einer VME-Bus-Karte sein (etwa bei einer Grafikkarte). “Maddalt()” erlaubt es, auch noch 
nach der Systeminitialisierung Blöcke von Altemate RAM in dieGEMDOS-Speicherliste ein¬ 
zuhängen. 

GEMDOS verwaltet ST-RAM und Alternate RAM in zwei völlig voneinander getrennten 
Listen. Wichtige Folge: Auf einem TT ist der freie Speicher bereits beim Systemstart segmen¬ 
tiert - in zwei große Blöcke aus ST-RAM bzw. Altemate RAM. 

GEMDOS nimmt sich dieser Problematik mit zwei verschiedenen Strategien an. Einerseits 
kann man im Header einer Programmdatei festlegen, ob der Programmcode im Altemate 
RAM liegen und ob Speicher aus dem Altemate RAM alloziert werden darf (mehr dazu 
später). Zusätzlich hat man mit “MxallocO” eine genaue Kontrolle darüber, welche RAM-Art 
benutzt wird. 

In den letzten Jahren hat sich die Qualität der Software signifikant verbessert. Daher kann man 
davon ausgehen, daß die “nächste” Rechnerfamilie von Atari auf Ebene der Hardware nicht 
mehr voll kompatibel sein wird (von der CPU aus der 68000-Familie abgesehen). Also: 
keinerlei direkte Zugriffe auf ST- oder TT-Hardware machen! Ein Programm, das heute nicht 
einwandfrei im Altemate RAM laufen kann, wird auf der nächsten Rechnergeneration erst 
recht nicht funktionieren. Wer direkt die Hardware ansprechen muß, sollte dies immer über 
eine Treiberschnittstelle - zum Beispiel über “Meta-DOS” - machen! 
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Prozesse 

Was ist ein GEMDOS-Prozeß? 

GEMDOS ist kein Multitasking-System, das heißt, es kann nicht mehr als ein Programm 
gleichzeitig ausgeführt werden. Dennoch sind die grundlegenden Strukturen dafür vorhanden: 
jedes geladene Programm wird von GEMDOS als eigenständiger Prozeß verwaltet. Mit Hilfe 
von “PexecO” können weitere Programme nachgeladen und wie ein Unterprogramm ausge¬ 
führt werden. Währenddessen wird das aufrufende Programm unterbrochen. 

GEMDOS merkt sich sämtlicheprozeßspezifischen Daten in der Basepage, einer Datenstruktur, 
die automatisch beim Programmstart angelegt wird. Zu den in der Basepage abgelegten Infor¬ 
mationen gehören: 

- Zeiger auf die Basepage-Struktur des aufrufenden Prozesses 

- Informationen über die verschiedenen Bestandteile des Programms nach dem Laden 

- Informationen über aktuelles Laufwerk und aktuelle Verzeichnisse 

- Informationen über die Zuordnung der Standardkanäle 
Informationen über die Tauglichkeit des Programms im “Altemate RAM” 

- Inhalte der Register, die nicht von GEMDOS verändert werden dürfen 

Alle diese Informationen werden also für jeden Prozeß separat gespeichert (auch wenn einige 
an nichtdokumentierten Stellen der Basepage verwahrt sind). Beim Starten eines Programms 
werden sie als aktuelle Einstellungen an den Kindprozeß weitervererbt. 

Dies ist auch eine der ganz wenigen Stellen, an denen GEMDOS über das Vorbild MS-DOS 
herausragt: dort werden die aktuellen Verzeichnisse nur einmal global verwaltet. Die Folge 
ist, daß nach Start eines Programms aktuelle Verzeichnisse und aktuelles Laufwerk verstellt 
sein können. 

Zu jedem Prozeß gibt es einen Elternprozeß , der ihn gestartet hat. Einzige Ausnahme ist der 
Urprozeß, der beim Aktivieren von GEMDOS angelegt wird. Damit ergibt sich eine Prozeß¬ 
hierarchie . Mit den aktuellen GEMDOS-Versionen kann man nur neue Prozesse erzeugen, 
indem man den aktuellen Prozeß bis zur Beendigung des aufgemfenen Programms suspendiert. 
Damitkannman sich die Prozeßhierarchie als Stapel vorstellen. Unter einem multitaskingfähigen 
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Betriebssystem wird das Ganze eher wie ein von einem Wurzelprozeß ausgehender Baum 
aussehen. 

GEMDOS kennt immer nur einen aktuellen Prozeß. Dazu gibt es im GEMDOS-Inneren die 
Zeigervariable “act_pd”, die auf die entsprechende Basepage-Struktur zeigt. “act_pd” ist 
keine echte Systemvariable, sondern vielmehr eine lokale Variable von GEMDOS. 

Zur Ermittlung ihrer Position gibt es von Atari ein Programmbeispiel (Quelle: “Rainbow TOS 
Release Notes”), das wir hier in abgewandelter Form abdrucken: 

/* Ermittle Adresse der GEMDOS-Variable act_pd. Die Funktion 
liefert also einen Zeiger auf einen BASEPAGE-Zeiger. 

Ab TOS 1.02 enthält der ROM-Header den Zeiger. In TOS 1.00 liegt 
der Zeiger bei Adresse $602C, es sei denn, es handelt sich um 
ein spanisches TOS (dann bei $8730 - 

Wichtiger Hinweis: funktioniert unter Umständen nicht mit 
gepatchten Versionen von TOS 1.00 */ 

BASEPAGE * *GetRun (void) 

{ 

LONG savessp = Super (OL); 

OSHEADER *0 = *((OSHEADER **)(0x4f2L)); 

Super ((void *) savessp); 

O = 0->os__beg; /* wegen Fehlers in alter AHDI-Version */ 

if (0->os_version < 0x102) 

{ 

if ((0->os_conf » 1) = 4) /* PAL-Modus wegshiften */ 

return ((BASEPAGE **)0x873c); /* Spanisches TOS 1.0 */ 
eise 

return ((BASEPAGE **)0x602c); 

1 

eise 

return 0->p_run; 

1 

Prinzipiell ist es damit möglich, zwischen zwei parallel laufenden GEMDOS-Prozessen hin- 
und herzuschalten. Doch Vorsicht: Diese Variable darf laut Atari auf keinen Fall verändert 
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werden. Probleme mit künftigen multitaskingfähigen GEMDOS-Versionen wären vor¬ 
programmiert! 

Die Basepage 

Die Basepage ist insgesamt 256 Bytes lang und hat folgende Struktur: 

typedef struct basepage 

{ 

void *p_lowtpa; /* Anfangsadresse der TPA (Offset 0) */ 
void *p_hitpa; /* Erstes Byte nach dem Ende der TPA 

(Offset 4) */ 

void *p_tbase; /* Anfangsadresse des Programmcodes (TEXT- 

Abschnitt) (Offset 8) */ 

LONG p_tlen; /* Länge des Programnicodes (Offset 12) */ 

void *p_dbase; /* Adresse des Bereichs für 

vorinitialisierte Daten (DATA-Abschnitt) 
(Offset 16) */ 

LONG p__dlen; /* Länge des Datenabschnitts (Offset 20) */ 

void *p_bbase; /* Adresse des Variablenbereichs (BSS- 

Abschnitt) (Offset 24) */ 

LONG p_blen; /* Länge des Variablenbereichs (Offset 28) */ 
DTA *p_dta; /* Zeiger auf Default-DTA (Vorsicht! Zeigt 

erst in die Kommandozeile) (Offset 32) */ 

struct basepage 

*p_parent; /* Zeigt auf die Basepage (BASEPAGE) des 

aufrufenden Prozesses (Offset 36) */ 
LONG p_resrvd0; /* reserviert */ 

CHAR *p_env; /* Adresse der Environment-Strings 

(Offset 44) */ 

CHAR p_resrvdl[80]; /* reserviert */ 

CHAR p_cmdlin[128]; /* Kommandozeile (dabei wird im ersten 

Byte die Anzahl der Zeichen einge¬ 
setzt. Die maximale Länge der 
Kommandozeile beläuft sich 
erstaunlicherweise nicht auf 127, 
sondern auf 124 Zeichen.) 

(Offset 128) */ 


} BASEPAGE; 
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Wichtiger Hinweis : der Zeiger “p_parent” ist zwar offiziell dokumentiert, sollte aber nicht 
dazu mißbraucht werden, in den Speicherbereich des Aufrufers zu schauen. 

Dies wäre ein eklatanter Verstoß gegen die Regel: “Du sollst nur auf Speicher zugreifen, der 
Dir selbst gehört”. 


TPA und Programmstart 

Die TPA (“Transient Program Area”) kommt beim Laden eines Programms ins Spiel. Die 
folgenden Informationen zum Ladevorgang beschreiben den (dokumentierten) IST-Zustand 
von GEMDOS. 

Manche Details könnten sich allerdings in künftigen GEMDOS-Versionen ändern. 

- Beim Programmstart wird der größte zusammenhängende Speicherbereich alloziert. Die 
Basepage wird in den ersten 256 Bytes der TPA angelegt. 

- Anschließend werden allen zu “vererbenden” Informationen aus der Basepage des auf¬ 
rufenden Programms übertragen. Der neuerzeugte Prozeß wird als Inhaber des durch die 
TPA belegten Speicherblocks eingetragen. Damit “gehört” der durch die TPA belegte 
Speicher dem gestarteten Programm. 

- Anschließend wird der Header der Programmdatei ausgewertet (eine detaillierte Schil¬ 
derung des Programmformats folgt später). 

Die Programmdatei wird geladen und die verbleibenden Felder in der Basepage gesetzt. 
Je nach Programmtyp wird das BSS-Segment oder der ganze verbleibende Rest der TPA 
gelöscht. 

- Dann bekommt der neue Prozeß einen eigenen Stack, der direkt am Ende der TPA 
beginnt (und bekanntlich nach unten - also nach den niedrigeren Adressen hin - wächst). 

- Als Parameter werden eine Null (LONG) und die Anfangsadresse der Basepage auf dem 
Stack übergeben. 

- Zuletzt wird der neue Prozeß zum aktuellen Prozeß gemacht und durch einen Sprung zum 
ersten Byte des Textsegments aktiviert. 

Den Aufbau der TPA entnehmen Sie bitte der Abbildung auf der folgenden Seite. 
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Stack 


Variablenbereich (BSS) 


Datenbereich (DATA) 


Programmcode (TEXT) 


Basepage 


High TPA (p_hitpa) 


p_bbase 

p_dbase 

p_tbase 

Low TPA (p_lowta) 


Je nach Speicheraufteilung beim Programmstart kann es also ohne weiteres passieren, daß der 
gesamte freie Speicher für das Programm reserviert worden ist. Das darf natürlich nicht so 
bleiben: 

- Viele Betriebssystemfunktionen (VDI, “fsel_input()”, “PexecO”) verbrauchen selbst 
Speicher! 

- Unter einem multitaskingfähigen Betriebssystem ist es ausgesprochen unpopulär, den 
gesamten freien Speicherplatz des Systems zu blockieren. Bereits jetzt gibt es einige 
TOS-Erweiterungen, unter denen dies zu berücksichtigen ist (beispielsweise das “Multi- 
GEM” der Maxon GmbH). 

Die Abhilfe ist einfach: 

1. Eigenen Stack einrichten. 

2. Überflüssigen Speicher wieder freigeben. 

3. Bei Bedarf innerhalb des Programms per “MallocO” Speicher nachfordem. 

Beim Einrichten des eigenen Stacks hat man verschiedene Möglichkeiten. Einerseits kann 
man von Beginn an ein entsprechend großes Stück der BSS fireihalten. Andererseits kann man 
sich natürlich auch einen Teil der “freien” TPA abknapsen. In beiden Fällen sollte man aber 
daran denken, daß der Stack zu niedrigeren Adressen hin wächst und der Stack-Pointer daher 
zu Beginn auf das Ende des freigehaltenen Speicherblocks zeigen muß! 
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Die TPA hat nunmehr diese Aufteilung (ob der Stack in oder über der BSS liegt, spielt in 
diesem Zusammenhang keine Rolle): 

High TPA (pjiitpa) 

Stack-Pointer 


p_bbase 

p„dbase 

p_tbase 

Low TPA (pjowta) 


freigewordener Speicher 


Stack 


Variablenbereich (BSS) 


Datenbereich (DATA) 


Programmcode (TEXT) 


Basepage 


Nun muß noch der freigewordene Speicher an GEMDOS zurückgegeben werden. Kein Pro¬ 
blem, da ja der durch die TPA belegte Speicherplatz dem Programm selbst gehört: 

1. Man berechne, wieviel Speicherplatz man braucht. Dazu summiere man die Länge der 
Basepage (256), des Text-, Data- und BSS-Segments sowie gegebenfalls des Stacks auf. 
Die Längen sind in der Basepage angegeben, deren Anfangsadresse als Parameter auf 
dem Stack (4(sp)) mitgeteilt wird. 

2. Der so erhaltene Wert ist die Anzahl der Bytes, auf die die TPA nun mit “MshrinkO” ge¬ 
schrumpft werden kann. 

Und so könnte der Code am Beginn des Textsegments aussehen: 


; Startup und Prozeßbeendigung 
; Assembler: Madmac 



.text 


move.1 

4(sp),aO 


lea 

MyStack,sp 


move.1 

#$100,dü 


add.l 

$c(a0) ,d0 


add.l 

$14(aO) ,d0 


add.l 

$lc(aO),d0 



Zeiger auf BASEPAGE-Struktur 
Stack-Pointer setzen 
Länge der Basepage 
Länge Text-Segment 
Länge Daten-Segment 
Länge BSS 
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move.1 

dO, -(sp) 

r 

Ergebnis auf den Stack 

move.1 

a0,- (sp) 

} 

BASEPAGE-Adresse auf den Stack 

clr .w 

- (sp) 

r 

Füllparameter 

move.w 

#$4a,-(sp) 

t 

GEMDOS Mshrink 

trap 

#1 

r 

GEMDOS-Trap 

lea 

$c(sp) ,sp 

/ 

Stack aufräumen 

jsr 

main 

f 

Hauptprogramm aufrufen 

move.w 

dO,-(sp) 

7 

Return-Wert des Programms 

move.w 

#$4c,~(sp) 

r 

GEMDOS Pterm 

trap 

#1 

/ 

GEMDOS-Trap 


.bss 




.ds.l 1000 

t 

4000 Bytes Stack 

MyStack: 

.ds.l 2 




Damit wäre dann die Anpassung der TPA beendet: 


Stack-Pointer 


p_bbase 
p_dbase 
p_tbase 

Low TPA (pjowta) 

GEMDOS kann den so freigegebenen Speicher nun wieder für andere Zwecke nutzen - zum 
Beispiel zum Starten weiterer Programme oder um Speicheranforderungen mittels “MallocO” 
zu bedienen. 

Nach Beendigung des eigenen Programms wird dann die gesamte TPA wieder freigegeben. 
Es sei noch auf zwei Sonderfälle hingewiesen: 

TSR-Programme (“Terminate und Stay Resident”) sind eine beliebte Methode, um Betriebs¬ 
systemerweiterungen oder -Veränderungen vorzunehmen. Beispiele smd“GDOS” (Betriebs- 


Stack 


Variablenbereich (BSS) 


Datenbereich (DATA) 


Programmcode (TEXT) 


Basepage 
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Systemergänzung bzw. -Vervollständigung), “Meta-DOS” (Betriebssystemerweiterung) oder 
“POOLFIX3” (Betriebssystemmodifikation), Besonderes Kennzeichen von TSR-Program- 
men ist, daß sie Betriebssystem-Vektoren modifizieren und dann resident im Speicher veran¬ 
kert werden. Dafür gibt es die Funktion “PtermresO”, die ein Programm beendet, dabei aber 
einen bestimmten Anteil der TPA nicht wieder freigibt. Die Anzahl der zu schützenden Bytes 
kann man genauso wie für “MshrinkO” berechnen. 

Wer die BASEPAGE-Struktur aufmerksam angesehen hat, wird festgestellt haben, daß die 
drei Programmsegmente gar nicht unbedingt in aufeinanderfolgenden Adreßbereichen liegen 
müssen. Damit wäre es prinzipiell denkbar, das Textsegment im ROM und die beiden anderen 
Segmente im RAM abzulegen. 

Dazu muß man allerdings bei Programmstart die Zeiger aus der Basepage beachten und nur 
indirekt über die Zeiger auf Variablen zugreifen. Wegen der eher geringen Bedeutung ROM- 
gestützter Programme bieten leider nur wenige Programmiersprachen die Möglichkeit, solche 
Programme zu erzeugen. 


Environment 

Auch die Environment-Strings sind ein Erbe von MS-DOS. Man beachte, daß es mehrere 
Environment-Strings geben kann, denn “p_env” zeigt auf eine Liste von Strings, die mit einer 
“0” abgeschlossen ist (am Ende der Strings stehen also zwei Nullen hintereinander). 

Bei jedem Programmstart mittels “PexecO” wird eine Kopie des aktuellen Environments 
gemacht und dem gestarteten Programm übergeben. Möchte man dabei ein geändertes 
Environment übergeben, dann muß man selbst eine erweiterte Kopie anlegen und bei 
“Pexec()” einen Zeiger darauf übergeben. Das Environment von Pnrenf-Prozessen kann nicht 
verändert werden. 

GEM hat ein eigenes Environment, das beim Starten der AES nach Ausführung der 
Programme im AUTO-Ordner festgelegt wird (weitere Informationen dazu bei der AES- 
Funktion “shel_envm()”). 

Das Standardformat für einen Environment-String sieht so aus: 

VARIABIE=Wert 

Variablenname und Wert sind also durch ein Gleichheitszeichen voneinander getrennt. Die 
einzige erlaubte Ausnahme gibt es beim ARGV-Verfahren zur Übergabe erweiterter Kom¬ 
mandozeilen. 
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Das ARGV-Verfahren 

Das ARGV-Verfahren zur Übergabe erweiterter Kommandozeilen ist nach langer (kontroverser) 
Diskussion im Herbst 1989 von Ken Badertscher (Atari Sunnyvale) offiziell spezifiziert 
worden (Ken Badertscher, “GEMDOS Extended Argument (ARGV) Specification”, in: 
INFO-ATARI 16 in Digest 595/89, (2. November 1989)). Es bietet folgende Vorteile gegen¬ 
über den herkömmlichen Kommandozeilen: 

- Die Anzahl und Größe der Parameter ist praktisch nur durch den freien Speicher 
begrenzt. 

- Einzelne Parameter dürfen auch Leerzeichen enthalten (in der normalen Kommandozeile 
sind die einzelnen Parameter untereinander durch Leerzeichen getrennt). 

- Als “nulltcr” Parameter kann der Name (mit Pfad) des gestarteten Programms übergeben 
werden. Das erlaubt es, in C-Programmen “argv[0]” zu setzen und den Namen, unter dem 
das Programm gestartet worden ist, festzustellen. 

Und so funktioniert das Ganze: Die Übergabe der erweiterten Kommandozeile erfolgt über 
das Environment. Die Environmentvariable ARGV (groß geschrieben!) zeigt an, daß dieses 
Verfahren benutzt wird. ARGV kann einen beliebigen Wert haben, allein seine Anwesenheit 
ist entscheidend. ARGV muß die letzte Environmentvariable sein, damit das aufgerufene 
Programm den “vorderen” Teil als sein normales Environment weiterbenutzen kann. 

Die erweitertete Kommandozeile wird als Folge von Null-terminierten Strings hinter ARGV 
ins Environment geschrieben. Der erste String (entspricht dem bislang nicht benutzten 
argvfO]) enthält den Namen des gestarteten Programms, wie man ihn auch an “Pexec()” 
übergibt. 

Die weiteren Strings enthalten die einzelnen Parameter, in denen auch Leerzeichen auftau¬ 
chen dürfen. Das Ende der Liste wird durch eine doppelte 0 gekennzeichnet (wie bei einem 
“normalen” Environment). Leider heißt das auch: leere Parameter können nicht übergeben 
werden (es gibt tatsächlich Fälle, in denen man so etwas braucht!). 

Zusätzlich übergibt man bei Pexec() als Längenbyte (erstes Byte in der Kommandozeile) den 
Wert 127, der wegen der existierenden Längenbeschränkung auf 125 Bytes bislang nicht 
angenommen werden konnte. 

Der Längenwert von 127 ermöglicht es dem aufgerufenen Programm, sicherzustellen, daß die 
im Environment übergebenen Werte tatsächlich gültig sind und nicht etwa von einem Pro¬ 
gramm, das den ARGV-Standard nicht kannte, übriggelassen wurden. 
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ARGV beim Aufrufer 

Um via ARGV-Parameter übergeben zu können, muß zunächst ein neues Environment für das 
aufzurufende Programm angelegt werden. Dazu berechnet man beispielsweise die Länge des 
bereits vorhandenen Environments, addiert die Länge der Kommandozeile und alloziert ent¬ 
sprechend viele Bytes. Dann wird das bestehende Environment kopiert (dabei gegebenenfalls 
eine bereits bestehende ARGV-Variable entfernt), die neue Variable ARGV und die Kom¬ 
mandozeilenparameter nacheinander angehängt (immer Null-terminiert). Eine letzte 0 
schließt dann das Environment legal ab. Beim Aufruf mittels “Pexee()” übergibt man im Län¬ 
genbyte der Kommandozeile den Wert 127. 

ARGV beim gestarteten Programm 

Zunächst muß man überprüfen, ob im Environment die Variable “ARGV” auftritt. Ist dies der 
Fall, und ist das Kommandozeilen-Längenbyte 127, dann findet man nach der ersten 0 nach 
“ARGV” (denn “ ARGV”kann ja einen Werthaben) die einzelnen Kommandozeilenparameter. 
Nachdem der Startupcode die Argument-Zeiger (in C: argv[i]) gesetzt hat, sollte noch der erste 
Buchstabe von “ARGV” auf 0 gesetzt werden - nun hat das Environment wieder die Standard- 
form. 


Programmformat unter GEMDOS 

Das GEMDOS-Programmformat hebt sich erheblich von dem einfacherer Betriebssysteme 
wie CP/M oder Atari-DOS (8-Bit) ab, da beim Programmstart das Programm an eine beliebige 
freie Stelle des Speichers geladen wird und dort ablauffähig sein muß. Dazu werden nicht die 
MC68K-spezifischen Adressierungsarten für indirekte Adressierung verwendet, sondern das 
geladene Programm kurzerhand für die entsprechende Stelle reloziert. Daher enthält eine 
GEMDOS-Programmdatei (wie sie mit “Pexec()” gestartet wird) zusätzlich noch Informatio¬ 
nen für den Relozierungsvorgang. Außerdem kann man zu Debugging-Zwecken auch die 
Symbole (Labels) in die endgültige Datei übernehmen. Alle dazu notwendigen Informationen 
stellt im Normalfall der Linker bereit, so daß der Programmierer selten damit in Berührung 
kommt. 

Eine GEMDOS-Programmdatei besteht also aus den aufeinanderfolgenden Komponenten: 

- Dateikopf 

- Text-, DATA- und BSS-Abschnitt 

- eventuell Symboltabelle 

- eventuell Relozierungstabelle 
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Der Datei-Kopf hat folgende Form: 


typedef struct 
{ 

WORD ph_branch; 

LONG ph_tlen; 

LONG ph_dlen; 

LONG ph_blen; 

LONG ph_slen; 

LONG ph_resl; 

LONG ph_prgflags; 
WORD ph_absflag; 

} PH; 


/* Branch an den Anfang des Programms 
(0x601A) */ 

/* Länge des TEXT-Abschnitts */ 

/* Länge des DATA-Abschnitts */ 

/* Länge des BSS-Abschnitts */ 

/* Länge der Symboltabelle */ 

/* reserviert; muß 0 sein */ 

/* spezielle Flags */ 

/* 0: Relozierungsinformationen vorhanden */ 


Im Feld “ph_prgflags” kann man weitere spezielle Flags angeben: 

Fastload-Flag 

Normalerweise löscht GEMDOS bei “Pexec()” die gesamte angelegte TPA. Das kann bei 
entsprechend viel RAM ziemlich viel Zeit in Anspruch nehmen (vor TOS 1.02 war zu allem 
Überfluß die Löschroutine besonders langsam). Wenn man Bit 0 in “ph_prgflags” setzt, wird 
lediglich dieBSS vorinitialisiert. Programme, die davon ausgehen, daß allozierte Speicherblöcke 
auch tatsächlich leer sind, fallen dann allerdings auf die Nase (ein Zeichen für unsaubere Pro¬ 
grammierung!). Doch Vorsicht: Anscheinend begehen auch Teile des Betriebssystems diesen 
Fehler, daher sollte man bei mindestens einem Auto-Ordner-Programm und einem Accessory 
das Fastload-Bit nicht setzen! 


TT-Speicher 

Beim TT kann man nicht mit allen Speicherbereichen das tun, was man vom ST gewohnt ist. 
Beispielsweise kann die Video-Hardware und die ACSI-DMA nur auf das ST-RAM zugreifen 
(mehr dazu bei der Hardware). Daher gibt es einen Mechanismus, mit dem man GEMDOS 
für ein bestimmtes Programm vorgeben kann, wohin es geladen werden soll und von wo aus 
Malloc()-Anforderungen bedient werden sollen. Wenn man Bit 1 in “ph_prgflags” setzt, heißt 
das für GEMDOS: Dieses Programm darf in das schnelle Altemate RAM geladen werden. Ein 
gesetztes Bit 2 signalisiert: Auch Malloc()-Anforderungen dieses Programms dürfen aus dem 
Altemate RAM bedient werden. 


Eine besondere Situation ergibt sich, wenn im Programmkopf angegeben ist, daß das 
Programm in das Altemate RAM geladen werden darf, jedoch im ST-RAM mehr Speicher als 
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im Altemate RAM frei ist. Für diesen Fall kann man festlegen, wieviel Altemate RAM 
“genug” für das Programm ist. Das TPA-Größen-Feld liegt in den obersten vier Bits von 
“phjprgflags”. Seine 16 möglichen Werte legen in Schritten zu 128 KByte den benötigten 
Speicher fest (0 steht dabei für 128 KByte, 15 für 2 MByte). Zum so ermittelten Wert wird 
außerdem noch die Summe der drei Programmsegmente (Code, Daten und BSS) addiert. 

Ein sauber geschriebenes Programm reserviert sich nach dem Programmstart in der TPA 
lediglich Platz für den Stack (Beispiel: der Startup-Code von Turbo-C). Bei solchen 
Programmen ist das TPA-Größen-Feld nur dann von Interesse, wenn ein ganz besonders 
großer Stack benötigt wird. Anders bei Programmen, die den größten Teil der TPA für sich 
behalten und nicht wieder mittels “MshrinkO” an GEMDOS zurückgeben. 


Symboltabelle 

Eine Symboltabelle im Digital-Research-Format besteht aus jeweils 14 Bytes langen Einträ¬ 
gen, die aus dem Symbolnamen (bis zu maximal acht Bytes; nur bei kürzeren Namen mit 0 
abgeschlossen!!), dem Symboltyp (zwei Bytes) und dem eigentlichen Symbolwert (vier 
Bytes) besteht. Folgende Symboltypen werden unterstützt: 


Wert 

Symboltyp 

$0100 

in der BSS 

$0200 

im Programmtext 

$0280 

TEXT FILE - Start eines Objektmoduls (nur mit “ALN”) 

$O2C0 

TEXT FILE ARCHIVE - Start einer Library (nur mit “ALN”) 

$0400 

im DATA-Bereich 

$0800 

Extemal 

$1000 

Register 

$2000 

Globales Symbol 

$4000 

Equated 

$8000 

Defined 


Viele Programmiersprachen benutzen allerdings ein eigenes Symbolformat (Mark-Williams- 
C, Turbo-C 2.0). 

Die Relozierungsinformationen 

Nach dem Ladevorgang wird das Programm automatisch reloziert. Dabei ist nur die 
Relozierung von 32-Bit-Werten (also Adressen) möglich. Vor GEMDOS 0.15 durften die 
Relozierungsinformationen maximal 32 Kbyte einnehmen. 
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GEMDOS kennt Programmdateien mit und ohne Relozierungsinformationen. Zur Unter¬ 
scheidung dient das Feld “ph_absflag” im Programmkopf. Nur wenn es 0 ist, wird die folgende 
Relozierungstabelle ausgewertet. 

Alte GEMDOS-Versionen (vor 0.15) gehen mit solchen Dateien allerdings nicht ganz korrekt 
um, daher empfiehlt Atari, statt dessen Dateien mit leerer Relozierungstabelle (siehe unten) 
zu verwenden. 

Die Relozierungstabelle beginnt mit einem 32-Bit-Wert, der den Offset des ersten zu relozie- 
renden Wertes relativ zum Beginn des Textsegments kennzeichnet. 

Für alle folgenden Offsets (zwischen den zu relozierenden Werten) werden einzelne Bytes 
benutzt. Auch für Abstände über dem Betrag eines Bytes (255) ist gesorgt: wird als Offset eine 
1 gefunden, was natürlich aufgrund der Eigenheiten des MC68Kausgeschlossen ist, wird auto¬ 
matisch zum Offset 254 addiert. 

Für besonders große Abstände zwischen zu relozierenden Werten kann dieser Vorgang auch 
mehrfach wiederholt werden. Ist die Relozierungstabelle leer, dann findet man als ersten 
Long-Wert eine 0. 


Weitere Standardformate 

Sehr ähnlich wie eine Programmdatei sieht eine Objektdatei im Digital-Research-Format aus: 

typedef struct 
{ 

WORD magic; 

LONG tsize; 

LONG dsize; 

LONG bsize; 

LONG ssize; 

CHAR reserved[10]; 

} OSHEADER; 

Schließlich noch das Format für das DR-Format für Archivdateien (oder auch Bibliotheken): 
eine Archivdatei enthält normalerweise weitere Objektdateien (kann aber auch beliebige 
andere Dateien enthalten). Der Dateikopf besteht lediglich aus dem Word $FF65. 

Es folgen beliebig viele Dateien, jeweils eingeleitet mit einer ARHEADER-Struktur. Das 
Ende der Archivdatei wird durch $0000 gekennzeichnet. 


/* $601A */ 

/* Größe des Textsegments */ 
/* Größe des DATA-Segments */ 
/* Größe der BSS */ 

/* Größe der Symboltabelle */ 
/* alle auf 0 setzen */ 
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typedef struct 
{ 


CHÄR 

a fname[14]; 

/* 

LONG 

a modti; 

/* 

BYTE 

a_userid; 

/* 

BYTE 

a_gid; 

/* 

WORD 

a_fimode; 

/* 

LONG 

a fsize; 

/* 

WORD 

reserved; 

/* 


Dateiname */ 

Zeitpunkt des letzten Zugriffs */ 
nicht benutzt */ 
nicht benutzt */ 

Filemodus */ 

Dateilänge */ 

0 */ 


} ÄRHEADER; 


GEMDOS-Vektoren 

Die Prozessoren der68000er~Reihe kennen 256 Vektoren, die für Dinge wieTraps, Exceptions 
oder Interrupts von I/O-Bausteinen verwendet werden, 

Ihre Adressen liegen in den ersten 1024 Bytes des Adreßraums (genaugenommen sind es nur 
die Vektoren 2 bis 255, und die Vektoren beginnen erst bei Adresse 8...). 

Zusätzlich sind für GEMDOS acht logische Vektoren (256 bis 263) definiert. Ihre Adressen 
liegen bei Adresse $400 (1024), sollten aber immer nur mit “SetexcQ” verändert werden - ihre 
tatsächliche Adresse muß nicht bei $400 liegen! Am Ende jeder Routine sollte zu der Adresse 
gesprungen werden, die “SetexcO” als bisherigen Inhalt des entsprechenden Vektors zurück¬ 
geliefert hat. 

Derzeit sind nur die ersten drei Vektoren benutzt - alle anderen sind für künftige Benutzung 
durch GEMDOS reserviert, 

Vektor 256: Systemtimer (etv timer) 

Dieser Vektor wird periodisch aufgerufen. Bei allen bisher bekannten Maschinen tritt der 
Aufruf 50mal pro Sekunde auf (intern wird dazu der 200-Hz-Timer benutzt). Darauf sollte man 
sich allerdings nicht verlassen, erhält man doch als einzigen Parameter auf dem Stack (4(sp)) 
die Anzahl der vergangenen Millisekunden. 

Hier install ierte Routinen sollten möglichst kurz gehalten werden - immerhin beeinflussen sie 
die Gesamtleistung des Rechners. Um das Retten der Register kümmert sich das System selbst, 
daher darf man alle Prozessorregister benutzen. 

GEMDOS benutzt den Systemtimer, um eine eigene Uhr zu führen. 
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Vektor 257: Critical Error Händler (etv_critic) 

Dieser Vektor gehört eigentlich eher zum BIOS - aber da ihn Atari auch unter den GEMDOS- 
Vektoren führt (GEMDOS Reference Manual), haben wir ihn auch hier dokumentiert. 

Das BIOS benutzt diesen Vektor, um auf kritische Fehler zu reagieren. Kritisch sind Fehler, 
die auf Probleme mit der Hardware (zum Beispiel nicht lesbare Sektoren) zurückzuführen 
sind. 

Wer nur ein Diskettenlaufwerk hat, weiß, daß das BIOS Zugriffe auf Laufwerk “B:” selbst 
abfangt und den Benutzer zum Einlegen der entsprechenden Diskette auffordert. Auch dieser 
Mechanismus wird mit Hilfe des Critical Error Händlers realisiert: man hat einfach den Zu¬ 
stand “andere Diskette muß eingelegt werden” als BIOS-Fehler definiert. 

Als ersten Parameter auf dem Stack (also bei 4(sp)) erhält man die Fehlernummer (als 16-Bit- 
Wort). Bei der Rückkehr aus dem Händler darf Register DO folgende Werte enthalten: 


Wert in dO 

Bedeutung 

$00010000 

Zugriff wiederholen (“Retry”) 

$00000000 

Fehler ignorieren 

$FFFFFFXX 

Mit BIOS-Fehler abbrechen (der Fehler wird dann im Normalfall an 
GEMDOS weitergereicht) 


Der Händler darf die Register D3 bis D7 und A3 bis A6 verändern. Aufrufe von GEMDOS- 
oder AES-Funktionen sind nicht erlaubt. Begründung: GEMDOS ist nicht re-entrant, und der 
Fehler könnte von einem GEMDOS-Aufruf ausgelöst worden sein. 

Aufrufe von AES-Funktionen könnten zu einer AES-Prozeß-Umschaltung führen - und wer 
weiß schon, ob der andere AES-Prozeß nicht vielleicht als nächstes einen GEMDOS-Aufruf 
vomimmt? 

Der Critical-Error-Handler in älteren GEM-Versionen (vor 3.0) hat leider einen Fehler, der 
in ungünstigen Fällen zum Systemabsturz führen kann: während die Alert-Box zu sehen ist, 
ist das AES-Prozeß-Switching nicht unterbunden. Daher könnte währenddessen ein Pro¬ 
gramm per Timer-Event zum Zuge kommen und selbst wieder einen GEMDOS-Aufruf tä¬ 
tigen. 

Ist die auf dem Stack übergebene Fehlemummer “-1” (also die Fehlemummer für “allgemeine 
Fehler”), und ist der installierte Händler der des AES, dann werden noch einige zusätzliche 
Werte auf dem Stack benutzt (dies ist nicht offiziell dokumentiert!): 
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Stack-Offset Bedeutung 

8(sp) Laufwerksnummer (0 ist A: etc) 

6(sp) BIOS-Fehlernummer 

Und hier ein Beispiel für einen Critical Error Händler, wie man ihn in rein textorientierten Pro¬ 
grammen (ohne GEM und Maus) benutzen kann, und der dem von MS-DOS ähnelt: 

; toscrit.s 

; Critical-Error Händler für Programme ohne Maus! 

; 30.09.89 

.globl toscritic 
.text 

toscritic: 


lea 

Message,aO 

r 

Fehlermeldung ausgeben 

bsr 

PrintIt 



move-1 

#$20002,-(sp) 



trap 

#13 

r 

Bconin von CON: 

addq.l 

#4, sp 



and.w 

#$5f,d0 



cmp.b 

#"A",d0 



beq 

IstA 



cmp.b 

#"R",d0 



beq 

IstR 



cmp.b 

#"I",dO 



bne 

toscritic 

} 

keine der drei Tasten -> von vorne 

clr. 1 

dO 

f 

Fehler ignorieren 

rts 




move.w 

4(sp),d0 

f 

Fehlernummer an GEMDOS melden 

ext.l 

dO 



rts 




moveq 

#l,d0 

r 

Retry zurückmelden 

swap 

dO 



rts 
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PrintIt: ; zeichenweise per BIOS ausgeben 

clr.l dO 
move.b (a0)+,d0 
tst.b dO 
beq endprint 

move.l a0,-(sp) 
move.w d0,-(sp) 
move.w #$2,-(sp) 
move.w #$3,-(sp) 
trap #13 
addq.l #6,sp 
move.l (sp)+,a0 
bra PrintIt 
endprint: 

rts 

.data 

Message: 

.dc.b 13,10 ; Zeilenvorschub 

.dc.b "BIOS-Brror: (A)bort, (R)etry, or (l)gnore?",0 

Vektor 258: Terminate Händler (etv_term) 

Dieser Vektor wird vor Prozeßbeendigung einmal durchsprungen (Merke: Programme, die per 
GEMDOS auf der Konsole ausgeben, können mit CTRL-C abgebrochen werden). Dies ist mit¬ 
hin die geeignete Stelle, um gegebenenfalls installierte Funktionen wieder zu deinstallieren. 
Nicht möglich ist es hingegen, irgendwelche GEMDOS-Aufrufe zu machen (GEMDOS ist 
nicht re-entrant, und an dieser Stelle steckt man mitten in einem GEMDOS-Aufruf) oder gar 
die Beendigung des Programms sauber zu verhindern. 


GEMDOS-Erweiterungen 

GEMDOS hat eine in vielerlei Hinsicht altmodische Architektur, die Erweiterungen recht 
schwer macht. Atari hat sich dieses Problems mit zweierlei Konzepten angenommen: 

Netzwerk-Standard und File-Locking 

Aus den oben genannten Gründen ist es ein schwieriges Unterfangen, Netzwerksoftware auf 
GEMDOS-Basis zu entwickeln. Lange Zeit kam erschwerend hinzu, daß es keinerlei Standard 
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in Hinsicht auf die zu implementierenden Funktionsaufrufe gab. Damit ist seit Frühjahr 1991 
Schluß: Atari hat die entsprechenden unter MS-DOS üblichen Definitionen übernommen 
(siehe in der Befehlsreferenz). Sie sind genau dann verfügbar, wenn der “_FLK”-Cookie 
gesetzt ist. Ein “_NET”-Cookie informiert über die Anwesenheit eines Netzwerks (nicht jedes 
Netzwerk beherrscht File-Locking, und File-Lockingkann auch ohne Netzwerk wichtig sein). 

Meta-DOS 

Meta-DOS ist eine GEMDOS-Erweiterung, die die Installation vielfältiger Gerätetreiber 
erlaubt. Dabei wird zwischen physikalischen Treibern (die man über erweiterte XBIOS- 
Aufrufe steuern kann) und logischen Treibern (die das Dateisystem übernehmen) unterschie¬ 
den. 

In Hinsicht auf GEMDOS-Aufrufe verhält sich Meta-DOS fast transparent. Bekannte Ein¬ 
schränkungen bzw. Unterschiede (Stand: Meta-DOS 1.7) sind: 

- die Laufwerksnummer darf bis “Z:” gehen 

- die Umlenkung der Standardkanäle auf von Meta-DOS verwaltete Dateien ist nicht 
möglich 

- Datei-Locking wird nicht unterstützt 

Meta-DOS kann von Entwicklern direkt von Atari bezogen werden und soll künftig allen Arten 
von GEMDOS-Treibern (CD-ROM, fremde Dateisysteme, Netzwerke) als Basis dienen. 

Bei Interesse sollten man sich beim Softwaresupport der jeweiligen Atari-Niederlassung 
melden. Die Linzenzbedingungen entsprechen denen von GDOS (einmalige Zahlung einer 
eher symbolischen Summe). 


GEMDOS mit Multitasking 

Aufgrund der an sich günstigen Ausgangsbasis haben sich auch unabhängige Entwickler der 
Weiterentwicklung vom GEMDOS angenommen. Schon seit langer Zeit gibt es “Micro- 
RTX” von Beckemeyer Development Tools, das GEMDOS in ein Echzeit-Multitasking- 
System (also mit möglichst kurzen und garantierten Prozeßwechselzeiten) zu verwandeln 
sucht. 

Ein anderer Versuch ist “MiNT” (“MiNT is Not TOS”) von Eric Smith, das als “offenes” 
Projekt (jeder kann die C-Quelltexte bekommen) entsteht. “MiNT” versucht, möglichst viele 
Eigenschaften von UNIX nachzubilden (Signale, Pipes etc). 
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GEMDOS-Bindings 

Ebenso wie BIOS und XBIOS empfängt auch GEMDOS seine Parameter auf dem Stack. 
Dabei wird das letzte Argument aus der Parameterliste als erstes auf den Stack gelegt. 

Schließlich wird durch die Anweisung “TRAP #1” der GEMDOS-Trap-Dispatcher aktiviert. 

Funktionsergebnisse werden im Prozessorregister DO zurückgeliefert. GEMDOS zerstört die 
Register D0-D2 und A0-A2. Nur bei den Registern D3-D7 und A3-A7 darf man sich darauf 
verlassen, daß sie nicht verändert werden. 

Vorsicht bei Aufrufen mit fehlerhaften Parametern! GEMDOS ist mit Sicherheit der instabil¬ 
ste Teil von TOS und ist äußerst leicht mit fehlerhaften Eingabedaten zu verwirren (“Garbage 
in -> Crash!”). 


Fehlermeldungen 

GEMDOS-Fehlermeldungen sind negative LONG-Werte zwischen -32 und -127. Bei den 
einzelnen Funktionen sind mögliche Fehlercodes angegeben. 

Man sollte sich allerdings nicht daraufverlassen, daß auch wirklich nur diese Fehlermeldungen 
auftreten können! Neben den folgenden Fehlermeldungen können auch alle BIOS-Return- 
Codes zurückgeliefert werden! 


0: E OK (“OK (no error)”) 

Funktion erfolgreich ausgeführt (kein Fehler aufgetreten). 

-32: EINVFN (“Invalid function number”) 

Unbekannte Funktionsnummer. Man erhält diese Meldung, wenn man eine Undefinierte 
GEMDOS-Funktion aufruft (unter MS-DOS: Fehlercode 1). 

-33: EFILNF (“File not found”) 

Datei nicht gefunden (unter MS-DOS: Fehlercode 2). 

-34: EPTHNF (“Path not found”) 

Angesprochener Ordner nicht gefunden (unter MS-DOS: Fehlercode 3). 
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-35: ENHNDL (“Handle pool exhausted”) 

Keine Dateihandles mehr (zu viele Dateien geöffnet, unter MS-DOS: Fehlercode 4). 

-36: EACCDN (“Access denied”) 

Zugriff nicht erlaubt (unter MS-DOS: Fehlercode 5). 

-37: EIHNDL (“Invalid handle”) 

Das Dateihandle war nicht korrekt (unter MS-DOS: Fehlercode 6). 

-39: ENSMEM (“Insufficient memory”) 

Nicht genügend Speicher vorhanden (unter MS-DOS: Fehlercode 8). 

-40: EIMBA (“Invalid memory block address”) 

Die Adresse des Speicherblocks war nicht gültig (unter MS-DOS: Fehlercode 9). 

-46: EDRIVE (“Invalid drive specification”) 

Die Laufwerksbezeichnung war ungültig (unter MS-DOS: Fehlercode 15). 

-^48: ENSAME (“Not the same drive”) 

Dateien sind auf verschiedenen logischen Laufwerken. 

-49: ENMFIL (“No more files”) 

Es können keine Dateien mehr geöffnet werden (unter MS-DOS: Fehlercode 18). 

-58: ELOCKED (“Record is locked”) 

Es wurde versucht, auf einen gelockten Bereich einer Datei zuzugreifen (nur im Zusammen¬ 
hang mit einer Netzwerk-GEMDOS-Version). 


-59: ENSLOCK (“No such lock”) 

Es wurde versucht, einen nicht existierenden Lock (falscher Offset oder/und falsche Länge) 
zu entfernen (nur im Zusammenhang mit einer Netzwerk-GEMDOS-Version). 
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-64: ERANGE (“Range error”) 

Dateizeiger in ungültigem Bereich. 

-65: EINTRN (“GEMDOS internal error”) 

Interner Fehler im GEMDOS (hoffentlich passiert’s nie!). 

-66: EPLFMT (“Invalid executable file format”) 

Das angesprochene Programm hat nicht das korrekte Format, um geladen zu werden. 

-67: EGSBF (“Memory block growth failure”) 

Es wurde versucht, einen allozierten Speicherblock zu vergrößern. 
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GEMDOS-Referenz 


Cauxin (GEMDOS 3) - Read character from Standard AUX: 


Mit dieser Funktion kann man Zeichen von Standardkanal 2 (das ist normalerweise die serielle 
Schnittstelle) empfangen (dabei wird gegebenenfalls so lange gewartet, bis ein Zeichen an der 
Schnittstelle vollständig eingetroffen ist!). 

Atari empfiehlt übrigens zu diesem Zweck die Verwendung der entsprechenden BIOS- 
Funktion. 


Deklaration in C: 

WORD Cauxin (void); 

Aufruf in Assembler: 

move.w #3,-(sp) ; Offset 0 

trap #1 

addq.l #2,sp 

Parameter: 

Cauxin(): Empfangenes Zeichen 

Bemerkungen 

Bei Ein-/Ausgabeumlenkung wird zur Zeit beim Dateiende ein Undefiniertes Zeichen 
zurückgegeben. 
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I Cauxis (GEMDOS 18) - Check Status of Standard AUX: input 

Mit dieser Funktion können Sie feststellen, ob von der seriellen Schnittstelle (d.h. vom 
Standardkanal 2) ein Zeichen empfangen werden kann. 

Atari empfiehlt die Verwendung der entsprechenden BIOS-Funktion. 

Deklaration in C: 

WORD Cauxis (void); 



Aufruf in Assembler: 

move.w #$12,-(sp) ; Offset 0 

trap #1 

addq.l #2,sp 

Parameter: 

Cauxis(): -1; Zeichen ist verfügbar 

0: Es liegt kein Zeichen vor 

Bemerkungen 

Arbeitet bei Ein-/Ausgabeumlenkung erst ab GEMDOS-Version 0.15 korrekt. 
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Cauxos (GEMDOS 19) - Check Status of Standard AUX: output 

Prüft, ob über die serielle Schnittstelle (Standardkanal 2) ein Zeichen ausgegeben werden kann 
oder nicht. 

Atari empfiehlt die Verwendung der entsprechenden BIOS-Funktion. 

Deklaration in C: 

WORD Cauxos (void); 

Aufruf in Assembler: 

move.w #$13,-(sp) ; Offset 0 

trap #1 

addq.l #2,sp 

Parameter: 

CauxosO: -1: Zeichen kann ausgegeben werden 

0: Zeichen kann nicht ausgegeben werden 
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Cauxout (GEMDOS 4) - Write character to Standard AUX: 


Zeichen wird auf Standardkanal 2 (dem seriellen Port) ausgegeben. 
Atari empfiehlt die Verwendung der entsprechenden BIOS-Funktion. 

Deklaration in C: 

void Cauxout (WORD c); 

Aufruf in Assembler: 

move.w c,-(sp) ; Offset 2 

move.w #4,-(sp) ; Offset 0 

trap #1 

addq.l #4,sp 


Parameter: 

c: Auszugebendes Zeichen (ASCII-Code in Bits 0..7, alle anderen Bits auf 0 setzen). 
Bemerkungen 

Arbeitet bei Ein-/Ausgabeumlenkung erst ab GEMDOS-Version 0.15 korrekt. 
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Cconin (GEMDOS 1) - Read charäcter from Standard iriput 


Ein Zeichen wird von stdin (also Standardkanal 0) gelesen (sobald eines vorliegt). Ist stdin die 
Tastatur, dann wird in den Bits 0..7 der ASCII-Code der gedrückten Taste und in den Bits 

16.. 23 der Scan-Code zurückgeliefert. 

Durch Setzen von Bit 3 der Systemvariablen “conterm” kann man veranlassen, daß in den Bits 

24.. 31 der Wert von “KbshiftO” zurückgegeben wird. 

Deklaration in C; 

LONG Cconin (void); 

Aufruf in Assembler: 

raove.w #l,-(sp) ; Offset 0 

trap #1 

addq.l #2,sp 

Parameter: 

Cconin(): eingelesenes Zeichen 

Bemerkungen 

Man hat weder die Möglichkeit festzustellen, ob I/O-Redirection stattfindet, noch die, das 
Dateiende zu erkennen. Daher definieren viele C-Bibliotheken analog zu MS-DOS den 
ASCII-Code 26 (also <Ctrl><Z>) als Zeichen für das Dateiende. 
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Cconis (GEMDOS 11) - Check Status of Standard input 


Diese Funktion überprüft, ob von stdin (Standardkanal 0, normalerweise die Tastatur) ein 
Zeichen eingelesen werden kann. 

Deklaration in C: 

WORD Cconis (void); 

Aufruf in Assembler: 

move.w #$B,-(sp) ; Offset 0 

trap #1 

addq.l #2,sp 

Parameter: 

Cconis(): 0: Zeichen nicht verfügbar 

-1: Zeichen verfügbar 


Cconos (GEMDOS 16) - Check Status of Standard output 

Liefert den Ausgabestatus von stdout (Standardkanal 1, normalerweise der Bildschirm). 

Deklaration in C: 

WORD Cconos (void); 

Aufruf in Assembler: 

move.w #$10,-(sp) ; Offset 0 

trap #1 

addq.l #2,sp 

Parameter: 

Cconos(): 1 (o.k.) oder 0 (Es kann kein Zeichen ausgegeben werden) 

Bemerkungen 

Arbeitet bei Ein-/Ausgabeumlenkung erst ab GEMDOS-Version 0.15 korrekt. 
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Cconout (GEMDOS 2) - Write character to Standard output 


Ein Zeichen wird auf stdout (Handle 1, normalerweise der Bildschirm) ausgegeben. 


Deklaration in C: 

void Cconout (WORD c); 


Aufruf in Assembler: 

move.w c, - (sp) 

move.w #2,-(sp) 

trap #1 

addq.l #4, sp 


; Offset 2 
; Offset 0 


Parameter: 

c: Auszugebendes Zeichen als 16-Bit-Wort (ASCH-Code in Bits 0..7, alle anderen Bits 
müssen 0 sein) 

Bemerkungen 

Arbeitet bei Ein-/Ausgabeumlenkung erst ab GEMDOS-Version 0.15 korrekt. 
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Cconrs (GEMDOS 10) - Read edited data from Standard input 


Mit dieser Funktion kann eine ganze Zeichenkette vom Standardeingabekanal, im Normalfall 
also der Tastatur, gelesen werden. 

Dazu schreibt man in das erste Element der LINE-Struktur die Anzahl der einzulesenden 
Zeichen (vermindert um 1 ).“Cconrs()” bricht die Eingabe in dem Moment ab, in dem der An¬ 
wender “Return” drückt oder die Maximallänge überschritten wird. 

Ein eventuelles Dateiende wird nicht erkannt! Umlaute (genauer: Zeichen mit ASCII-Code 
größer als 127) werden erst ab GEMDOS-Version 0.15 korrekt behandelt. 


Eingabefunktionen: 

<Retum>, CTRL-J 
<Backspace>, CTRL-H 
CTRL-U, CTRL-X 
CTRL-R 
CTRL-C 


Ende der Eingabe 
Letztes Zeichen löschen 
Ganze Zeile löschen 
Zeile neu eingeben 

Programm abbrechen (siehe dazu auch “etvjerm”) 


Deklaration in C: 


/* maximale Länge der Eingabe */ 

/* tatsächliche Länge, Offset 1 */ 
/* eingelesene Zeichen, Offset 2 */ 


void Cconrs (LINE *buf); 


typedef struct 
{ 

BYTE maxien; 

BYTE actuallen; 
CHAR buffer[255]; 
} LINE; 


Aufruf in Assembler: 

pea buf ; Offset 2 

move.w #$Ä,-(sp) ; Offset 0 

trap #1 

addq.l #6,sp 
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Parameter: 

buf->maxlen: Anzahl der einzulesenden Zeichen (-1) 

buf->actuallen: Tatsächlich gelesene Zeichen 

buf->buffer. Die eingelesene Zeichenkette 

Bemerkungen 

Gelesene Zeichen werden selbst dann auf dem Bildschirm ausgegeben, wenn die 
Standardausgabe auf eine Datei umgelenkt worden war. 
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Cconws (GEMDOS 9) - W 

rite string to Standard output 


Mit dieser Funktion kann eine ganze Zeichenkette auf stdout (also normalerweise dem 
Bildschirm) ausgegeben werden. Als Endmarke für den String wird - wie gewohnt - die 0 
verwendet. 

Deklaration in C: 

void Cconws (const char *str); 


Aufruf in Assembler: 

pea str ; Offset 2 

move.w #9,-(sp) ; Offset 0 

trap #1 

addq.l #6,sp 


Parameter: 

str: auszugebende Zeichenkette (muß mit 0 abgeschlossen sein) 

Bemerkungen 

Einige Dokumentationen (auch zurückliegende Auflagen des Profibuchs) geben als 
Rückgabewerte die Anzahl der ausgegebenen Zeichen an. Dieses Verhalten ist jedoch offiziell 
nicht dokumentiert und sollte daher nicht ausgenutzt werden! 
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Cnecin (GEMDOS 8) - Read character from Standard input, no echo 


Entspricht “CrawcinO” mit der Ausnahme, daß Steuerzeichen (<CtrlxS> Bildschirmausgabe 
stoppen, <CtrlxQ> Bildschirmausgabe fortsetzen, <CtrlxCC Abbruch usw.) korrekt inter¬ 
pretiert werden. 


Deklaration in C: 

LONG Cnecin (void); 


Aufruf in Assembler: 

move.w #8,-(sp) ; Offset 0 

trap #1 

addq.l #2,sp 


Parameter: 

Cnecin(): das eingelesene Zeichen 
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Cprnos (GEMDOS 17) - Check Status of Standard PRN: 


Liefert den Ausgabestatus der parallelen Schnittstelle (Standardkanal 3). 

Es empfiehlt sich dringend, diese Funktion vor jeder Druckausgabe zu nutzen, da bis zum 
Erkennen des Drucker-”Timeouts” eine halbe Ewigkeit (ungefähr eine halbe Minute) vergeht 
und die Geduld der Anwender meist sehr eingeschränkt ist. 


Deklaration in C: 

WORD Cprnos (void); 


Aufruf in Assembler: 

move.w #$11,-(sp) ; Offset 0 

trap #1 

addq.l #2,sp 

Parameter: 

Cpmos(): 0: Drucker nicht empfangsbereit 

-1: Drucker empfangsbereit 
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Cprnout (GEMDOS 5) - Write character to Standard PRN: 


Ein Zeichen wird auf Standardkanal 3 (dem Drucker) ausgegeben. Dabei werden die über 
“SetprtO” vorgenommenen Einstellungen (die man zum Beispiel über das Kontrollfeld 
vornehmen kann) aufgrund eines Fehlers in allen bekannten TOS-Versionen nicht berücksich¬ 
tigt. 

Es empfiehlt sich, vorher mittels “CpmosO” festzustellen, ob der Drucker überhaupt Zeichen 
empfangen kann. 


Deklaration in C: 

WORD Cprnout (WORD c); 


Aufruf in Assembler: 

move.w c,-(sp) ; Offset 2 

move.w #5,-(sp) ; Offset 0 

trap #1 

addq.l #4,sp 


Parameter: 


c: auszugebendes Zeichen in Bits 0..7, alle anderen Bits müssen auf 0 gesetzt sein 

Cpmout(); Es wird der Rückgabewert der entsprechenden BIOS-Funktion zurückgeliefert 

(0: o.k., sonst: Fehler). Der ist allerdings nur dann definiert, wenn tatsächlich 
auf die parallele Schnittstelle ausgegeben wurde! 

Bemerkungen 

Arbeitet bei Ein-/Ausgabeumlenkung erst ab GEMDOS-Version 0.15 korrekt. 
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Crawcin (GEMDOS 7) - Raw input from Standard input 

Ein Zeichen wird von stdin (der Tastatur) gelesen, ohne daß es dabei sofort auf dem Bildschirm 
ausgegeben wird. <CtrIxC> wird dabei ignoriert, 

Deklaration in C: 

LONG Crawcin (void); 

Aufruf in Assembler: 

move.w #7,-(sp) ; Offset 0 

trap #1 

addq.l #2,sp 

Parameter: 

Crawcin(): das eingelesene Zeichen 


Bemerkungen 

Bei Ein-/Ausgabeumlenkung wird zur Zeit beim Dateiende ein Undefiniertes Zeichen 
zurückgegeben. 







GEMDOS 


219 


Cravvio (GEMDOS 6) - Raw I/O to Standard input/oütput 


Dies ist eine Vielzweckfunktion zur Ein- und Ausgabe auf stdin (Tastatur) und stdout (Bild¬ 
schirm). <CtrlxC> wird dabei ignoriert. 


Deklaration in C: 

LONG Crawio (WORD w); 


Aufruf in Assembler: 


move,w 
move.w 
trap 
addq.l 


w,-(sp) ; Offset 2 
#6,-(sp) ; Offset 0 
#1 

#4, sp 


Parameter: 

w: $FF: Zeichen von stdin einlesen (entspricht “CconinQ”) 

sonst: Zeichen auf stdout ausgeben (entspricht “CconoutO”) 

Crawio(): (für w=$FF) das eingelesene Zeichen wie bei “CconinO” oder 0 (kein Zeichen 

verfügbar). 


Bemerkungen 

Arbeitet bei Ein-/Ausgabeumlenkung erst ab GEMDOS-Version 0.15 korrekt. 
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Dcreate (GEMDOS 57) - Create directory 


Legt neue Ordner (Subdirectories) an. 


Deklaration in C: 

WORD Dcreate (const char *pathname); 

Aufruf in Assembler: 

pea pathname ; Offset 2 

move.w #$39,~(sp) ; Offset 0 

trap #1 

addq.l #6,sp 


Parameter: 

pathname: Zeiger auf einen gültigen Ordnemamen 

Dcreate(): einige mögliche Return-Werte: 

OK (0): alles in Ordnung 

EPTHNF (-34): Ordner nicht gefunden 

EACCDN (-36): Zugriff verwehrt 

Bemerkungen 

Vor GEMDOS 0.15 machte “DcreateO” praktisch keine Fehlerbehandlung. Dadurch konnte 
sogar im schlimmsten Fall das Datei System in Mitleidenschaft gezogen werden. Ebensowenig 
wurde vorher geprüft, ob es nicht bereits eine Datei mit gleichem Namen gibt (die Datei wurde 
dann einfach gelöscht). 
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Ddelete (GEMDOS 58) - Delete direclory 

Löscht einen Ordner (der dazu leer sein muß). 


Deklaration in C: 

WORD Ddelete (const char *pathname); 

Aufruf in Assembler: 

pea pathname ; Offset 2 

move.w #$3A,-(sp) ; Offset 0 

trap #1 

addq.l #6,sp 


Parameter: 


pathname: 

DdeleteQ: 


Zeiger auf den entsprechenden Ordnemamen. 
einige mögliche Return-Werte: 


OK (0): 

EPTHNF (-34): 
EACCDN (-36): 

EINERN (-65): 


alles in Ordnung 
Ordner nicht gefunden 

Zugriff verwehrt (Ordner enthält Dateien, die vorher 
einzeln gelöscht werden müssen) 

Interner Fehler (?) 


Bemerkungen 

Vor GEMDOS 0.15 funktionierte ein “DcreateO” unmittelbar gefolgt von einem “DdeleteO” 
nicht (erst ein weiterer Aufruf von “DdeleteO” führte zum gewünschten Ergebnis). 
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Dfree (GEMDOS 54) - Get drive free space 


Mit “DfreeO” kann man diverse Informationen Uber ein bestimmtes logisches Laufwerk 
erfragen. Die Informationen werden in einer DISKINFO-Struktur abgelegt: 

typedef struct 
{ 

LONG bjfree; /* Anzahl der freien Cluster */ 

LONG b_total; /* Gesamtzahl der Cluster */ 

LONG b_secsiz; /* Bytes pro Sektor */ 

LONG b_clsiz; /* Sektoren pro Cluster /* 

} DISKINFO; 


Deklaration in C: 

LONG Dfree (DISKINFO *buf, WORD drv); 


Aufruf in Assembler: 


move.w 
pea 

move.w 
trap 
addq.1 


drv,-(sp) 
buf 

#$36,-(sp) 
#1 

#8, sp 


; Offset 6 
; Offset 2 
; Offset 0 


Parameter: 

drv: 0: aktuelles Laufwerk 

1: A: 

2: B: (usw.) 

buf: Anfangsadresse des DISKINFO-Puffers 

Dfree(): einige mögliche Return-Werte: 

OK (0): alles in Ordnung 

Bemerkungen 

Auf GEMDOS-Versionen vor 0.15 (“Rainbow-TOS”) war diese Funktion lächerlich langsam. 
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Dgetdrv (GEMDOS 25) - Get default drive 


Liefert die Nummer des aktuellen Laufwerks. 

Deklaration in C: 

WORD Dgetdrv (void); 

Aufruf in Assembler: 

move.w #$19,-(sp) ; Offset 0 

trap #1 

addq.l #2,sp 

Parameter: 

Dgetdrv(): 0: Laufwerk A: 

1: Laufwerk B: 

2: Laufwerk C: 

usw. 
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Liefert den Pfadnamen für das aktuelle Teilverzeichnis. 


Es ist eine konzeptionelle Schwäche des GEMDOS, daß die maximale Länge von Verzeich¬ 
nisnamen nicht begrenzt ist, aber auch nicht vorher abgefragt werden kann. 

Ursache für dieses merkwürdige Verhalten ist, daß GEMDOS erst bei “Dgetpath()” den 
vollständigen Pfad zusammenkopiert. Es bleibt also nichts anderes übrig, als “DgetpathO” 
einen “ausreichend” langen Puffer zu übergeben. 

Ein sinnvoller Wert dürfte beispielsweise 256 Zeichen sein, da das Desktop selbst auch keine 
längeren Pfade verwalten kann. 

Deklaration in C: 

WORD Dgetpath (char *buf, WORD driveno); 

Aufruf in Assembler: 

move.w driveno,-{sp) 
pea buf 

move.w #$47,-(sp) 

trap #1 

addq.l #8,sp 

Parameter: 

buf: Zeiger auf einen Puffer, der nach dem Aufruf den aktuellen Zugriffspfad enthält 

drv: 0: aktuelles Laufwerk 

1: A: 

2: B: 

usw. 

Dgetpath(): einige mögliche Return-Werte: 

OK (0): alles in Ordnung 

EDRIVE (-46): Falsche Laufwerksnummer 


; Offset 6 
; Offset 2 
; Offset 0 
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Dsetdrv (GEMDOS 14) - Set default drive 


Die Nummer des aktuellen Laufwerks wird gesetzt. 


Deklaration in C: 

LONG Dsetdrv (WORD drv); 

Aufruf in Assembler: 

move.w drv,-(sp) ; Offset 2 
move.w #$E,-(sp) ; Offset 0 

trap #1 

addq.l #4,sp 


Parameter: 

drv: Nummer des neuen aktuellen Laufwerks (0: A, 1: B...) 

Dsetdrv(): Bitvektor mit den vorhandenen Laufwerken (Bit 0: A:,...) 

Bemerkungen 

Vorsicht! Bei vielen Compilern ist der Return-Wert dieser Funktion fälschlich als “WORD” 
deklariert. 

Und noch einmal Vorsicht! GEMDOS macht bei dieser Funktion überhaupt keine 
Plausibilitätstests, so daß eine falsche Laufwerksnummer (außerhalb des erlaubten Bereichs) 
zu schweren Schäden in GEMDOS-intemen Strukturen führen kann! 

Einen Bitvektor mit den von GEMDOS unterstützen Laufwerken beschafft man sich am 
besten mit: 

Dsetdrv (Dgetdrv ()); 

Zur Zeit ist der zurückgelieferte Bitvektor das Resultat des BIOS-Aufrufs “DrvmapO”. Dies 
ist jedoch nicht dokumentiert und könnte sich ohne weiteres eines Tages ändern. 
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Dsetpath (GEMDOS 59) - Set current directory 


Setzt den neuen aktuellen Zugriffspfad für das aktuelle Laufwerk. GEMDOS merkt sich für 
jedes logische Laufwerk einen aktuellen Zugriffspfad. “Dsetpathö” sollte nur für das aktuelle 
Laufwerk benutzt werden. Zum Setzen des aktuellen Pfades auf einem anderen Laufwerk 
sollte man etwa folgende Sequenz benutzen: 

1. Aktuelles Laufwerk abfragen 

2. Gewünschtes Laufwerk setzen 

3. Pfad für das Laufwerk setzen 

4. Gemerktes Laufwerk wieder zum aktuellen Laufwerk machen 


Deklaration in C: 

WORD Dsetpath (const char *path); 


Aufruf in Assembler: 


pea 

move.w 
trap 
addq. 1 


path 

#$3B, - (sp) 
#1 

#6, sp 


; Offset 2 
; Offset 0 


Parameter: 

path: Pfadname für den neuen aktuellen Zugriffspfad 

Dsetpath(): einige mögliche Return-Werte: 

OK (0): alles in Ordnung 

EPTHNF (-34): Ordner nicht gefunden 

Bemerkungen 

Auf älteren GEMDOS-Versionen führt das häufige Setzen nichtexistenter Pfade zu GEMDOS- 
intemen Störungen (Verlust von Pfadkontrollstrukturen). Mögliche Folge ist, daß selbst 

Dsetpath ("\\"); /* Pfad auf Wurzelverzeichnis setzen */ 


zu einem Fehler führt. 
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Fattrib (GEMDOS 67) - Get/Set Ule attributes 

Liest oder setzt die Dateiattribute einer Datei, 

Deklaration in C: 

WORD Fattrib (const char *fname, WORD wflag, WORD attribs); 

Aufruf in Assembler: 

move.w attribs,- (sp) 
move.w wflag,-(sp) 

pea fname 

move.w #$43,-(sp) 

trap #1 

lea $A(sp),sp 

Parameter: 

fname: Dateiname der betreffenden Datei (ggfs, mit Zugriffspfad, sonst im aktuellen 

Teilverzeichnis) 

wflag: 0: die aktuellen Attribute werden nur ausgelesen und zurückgeliefert 

(attribs wird ignoriert) 

1: die Dateiattribute der angegebenen Datei werden auf den in attribs ange¬ 

gebenen Wert gesetzt 
attribs: Dateiattribute: 

Bit 0: Datei schreibgeschützt 
Bit 1: Datei versteckt (“hidden”) 

Bit 2: Systemdatei 

Bit 3: Diskettenname 

Bit 4: Teil Verzeichnis (Ordner) 

Bit 5: Archiv-Bit 

Fattrib(): die bisherigen Dateiattribute oder: 

EFILNF (-33): Datei nicht gefunden 
EPTHNF (-34): Ordner nicht gefunden 
oder eine andere Fehlermeldung 


; Offset 8 
; Offset 6 
; Offset 2 
; Offset 0 
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Schließt eine mit “FopenQ” oder “FcreateO” geöffnete Datei. 


Deklaration in C: 

WORD Fclose (WORD handle); 

Aufruf in Assembler: 

move.w handle,-(sp) ; Offset 2 

move.w #$3E,-(sp) ; Offset 0 

trap #1 

addq.l #4,sp 

Parameter: 

handle: Kennung der zu schließenden Datei 

Fclose(): einige mögliche Return-Werte: 

OK (0): alles in Ordnung 

EIHNDL (-37): Dateikennung war falsch! 

Bemerkungen 

Was beim Schließen von Standardkanälen passiert, ist erst ab GEMDOS 0.15 definiert: es wird 
wieder der ursprüngliche zeichenorientierte Kanal eingesetzt. 
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Fcreate (GEMDOS 60) - Create file 

Unter GEMDOS gibt es zwei Möglichkeiten, eine Datei zum Schreiben zu öffnen: mit 
“FcreateO” kann man eine völlig neue Datei erzeugen. Existiert dabei bereits eine Datei mit 
diesem Namen, wird sie dabei überschrieben. Mit “FopenO” dagegen kann man nur bereits 
existierende Dateien öffnen. 

Die Moral von der Geschieht’: Ausgabedateien öffnet man mit “FopenO” nicht! 

Deklaration in C: 

WORD Fcreate {const char *fname, WORD attribs); 

Aufruf in Assembler: 

move.w att ribs,- (sp) 

pea fname 

move.w #$3C,-(sp) 

trap #1 

addq.l #8,sp 

Parameter: 

fname: Zeiger auf den Dateinamen (dabei kann auch der Zugriffspfad angegeben 

werden, ansonsten wird das aktuelle Teilverzeichnis benutzt), 
attribs: Bit 0: Datei schreibgeschützt 

Bit 1: Versteckte Datei 
Bit 2: Systemdatei 

Bit 3: Diskettenname (sollte auf jeder Diskette nur einmal vorhanden sein!) 
Fcreate(): Kennung der Datei oder 

EPTHNF (-34): Zugriffspfad war nicht korrekt 

ENHNDL (-35): Keine freien Dateikennungen (handles) mehr 
EACCDN (-36): Kein Schreibzugriff möglich 

oder eine andere Fehlermeldung 

Bemerkungen 

Vorsicht bei der Benutzung von Wildcards: eine Dateiangabe wie “TEST*.*” wird von 
GEMDOS intern zunächst zu “TEST????.???” expandiert. Unter diesem (nicht erlaubten) 
Namen wird die Datei dann auch tatsächlich angelegt! 


; Offset 6 
; Offset 2 
; Offset 0 
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Bei Verwendung eines netzwerkfahigen GEMDOS (Cookie “_FLK” testen!) ist die Datei 
exklusiv für den anlegenden Prozeß zugänglich. 

Den Diskettennamen kann man folgendermaßen neu setzen: 

IF GEMDOS-Version <0.15 

IF Volume-Label schon vorhanden 

Datei gleichen Namens mit FcreateO anlegen, mit FcloseQ 
schließen und mit Fdelete() wieder löschen 
ENDIF 
ENDIF 

Diskettennamen mit FcreateO anlegen und das zurückgelieferte 
Handle mit Fclose () wieder freigeben. 



GEMDOS 


231 


Fdatime (GEMDOS 87) - Get/Set file timestamp 


Setzt oder ermittelt Uhrzeit und Datum der Erstellung einer Datei (die man zuvor mit 
“FopenO” oder “FcreateO” geöffnet hat). Zur Zeitübergabe wird folgende Struktur benutzt: 

typedef struct 
f 

UWORD time; /* Zeit wie in "Tgettime" */ 

UWORD date; /* Datum wie in "Tgetdate" */ 

} DOSTIME; 

Deklaration in C: 

void Fdatime (DOSTIME *timeptr, WORD handle, WORD wflag); 


Aufruf in Assembler: 


move.w 

move.w 

pea 

move.w 

trap 

lea 


wflag,-(sp) 
handle, -(sp) 
timeptr 
#$57,-(sp) 

#1 

$A(sp),sp 


; Offset 8 
; Offset 6 
; Offset 2 
; Offset 0 


Parameter: 

handle: Dateikennung der betreffenden Datei 

timeptr: Zeiger auf eine DOSTIME-Struktur 

wflag: 0: Aktuelle Werte in DOSTIME-Struktur übertragen 

1: Werte aus DOSTIME-Struktur in Directory eintragen 


Bemerkungen 

Wegen einiger Fehler in alten GEMDOS-Versionen sollte man “FdatimeO” stets auf folgende 
Art und Weise benutzen: 

1. Datei öffnen 

2. “FdatimeO” aufrufen 


3. Datei sofort wieder schließen 
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Fdelete (GEMDOS 65) - Delete file 

Löscht die angegebene Datei. 

Deklaration in C: 

WORD Fdelete (const char *fname); 

Aufruf in Assembler: 

pea fname 

move.w #$41,-(sp) 

trap #1 

addq.l #6,sp 

Parameter: 

fname: Name der betreffenden Datei (evtl, mit Zugriffspfad) 

Fdelete(): einige mögliche Retum-Werte: 

OK (0): alles in Ordnung 

EFELNF (-33): Datei nicht gefunden 

EACCDN (-36): Zugriff verwehrt (Datei schreibgeschützt?) 

Bemerkungen 

Es ist nicht möglich, geöffnete Dateien zu löschen -es sei denn, man selbst ist der einzige Pro¬ 
zeß, der die Datei geöffnet hat. In diesem Fall wird die Datei erst geschlossen und dann ge¬ 
löscht. Leider tritt dabei ein Fehler auf: Die Dateikennung wird nicht wieder freigegeben .Also: 
geöffnete Dateien nicht löschen! 


; Offset 2 
; Offset 0 






GEMDOS 


233 


Fdup (GEMDOS 69) - Duplicate file handle 


Für den angegebenen Standardkanal (0. .5) wird eine zweite Kennung (handle) geliefert (siehe 
auch “FforceO”). 

In allen bekannten GEMDOS-Versionen (bis einschließlich 0.19) treten Fehler auf, wenn nach 
“FdupO” noch ein Programm mittels “Pexecö” gestartet wird. 

Deklaration in C: 

WORD Fdup (WORD handle); 

Aufruf in Assembler: 

move.w handle,-(sp) ; Offset 2 

move.w #$45,-(sp) ; Offset 0 

trap #1 

addq.l #4,sp 


Parameter: 

stdhandle: Nummer des Standardkanals: 

0: Tastatur (stdin) 

1: Bildschirm (stdout) 

2: Serielle Schnittstelle (stdaux) 

3: Parallele Schnittstelle (stdpm) 

Fdup(): Neue Kennung oder: 

ENHNDL (-35): keine freien Kennungen mehr 

EIHNDL (-37): falsche Kennung (handle) 

oder eine andere Fehlermeldung 
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Fforce (GEMDOS 70) - Force file handle 


Der Schlüssel zur “Input/Output-Redirection”: biegt einen Standardkanal (0..5) auf einen 
beliebigen anderen Kanal um. 


Deklaration in C: 

WORD Fforce (WORD stdh, WORD nonstdh); 


Aufruf in Assembler: 

move.w nonstdh,-(sp) 

move.w stdh,-(sp) 

move.w #$46,-(sp) 

trap #1 

addq.l #6,sp 


; Offset 4 
; Offset 2 
; Offset 0 


Parameter: 


stdh: 


nonstdh: 


FforceQ: 


Nummer des umzuleitenden Kanals: 

0: Tastatur (stdin) 

I: Bildschirm (stdout) 

2: Serielle Schnittstelle (stdaux) 

3: Parallele Schnittstelle (stdpm) 

Nummer des ersetzenden Kanals (muß vorher mit “FopenO” oder “Fcreate()” 
geöffnet worden sein. Mit “FdupO” kann man ein “nonstdhandle” für einen 
Standardkanal besorgen). Mit “Fforce (1, Fdup (3))” könnte man also beispiels¬ 
weise alle Bildschirmausgaben an den Drucker umleiten! 
einige mögliche Return-Werte: 

OK (0): alles in Ordnung 

EIHNDL (-37): Falsche Kennung (handle) 
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Fgetdta (GEMDOS 47) - Get DTA 


Liefert die Anfangsadresse der aktuellen DTA (Siehe auch unter “Fsfirst()” und “Fsnext()”>: 

typedef struct 
{ 


BYTE d_reserved[21]; 

/* 

fürs GEMDOS reserviert */ 

BYTE d attrib; 

/* 

Dateiattribut */ 

UWORD d_time; 

/* 

Uhrzeit */ 

DWORD d_date; 

/* 

Datum */ 

LONG d_length; 

/* 

Dateilänge */ 

char d fname[14]; 

/* 

Dateiname */ 


} DTA; 

Deklaration in C: 

DTA *Fgetdta (void); 

Aufruf in Assembler: 

move.w #$2F,-(sp) ; Offset 0 

trap #1 

addq.l #2,sp 


Parameter: 

Fgetdta(): Zeiger auf die aktuelle DTA 
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Flock (GEMDOS 92) - Lock file 


Diese Funktion ist nur unter einem netzwerkfähigen GEMDOS (“_FLK“-Cookie testen!) 
verfügbar. 

Sie dient dazu, Teile von Dateien gegen den Zugriff von anderen Prozessen (Benutzern) zu 
schützen. 


Deklaration in C: 

LONG Flock (WORD handle, WORD mode, LONG Start, LONG length); 


Aufruf in Assembler: 

move.1 length,-(sp) 

move.l Start,-(sp) 

move.w mode,-(sp) 

move.w handle,-(sp) 

move.w #$5C,-(sp) 

trap #1 

lea $C(sp),sp 


; Offset 10 
; Offset 6 
; Offset 4 
; Offset 2 
; Offset 0 


Parameter: 

handle: Kennung der betreffenden Datei 

mode: 0: “length” Bytes ab Position “start” blockieren (“locken”) 

1: Blockierung aufheben. “length” und “start” müssen exakt zu einer exi¬ 

stierenden Blockierung passen! 
start: Startposition in der Datei 

length: Anzahl der Bytes 

Flock(): einige mögliche Return-Werte: 

OK (0): alles in Ordnung 

ELOCKED (-58): Blockierung (Lock) bereits vorhanden 

(Dateiausschnitt ist bereits blockiert bzw. überlappt ei¬ 
nen blockierten Ausschnitt.) 

ENSLOCK (-59): Entsprechende Blockierung existiert nicht 

(Es wurde versucht, eine nicht vorhandene Blockierung 
aufzuheben.) 


Bemerkungen 

Siehe Hinweise zum Atari-Netzwerkstandard in der GEMDOS-Einführung. 
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Fopen (GEMDOS 61) - Open file 


Öffnet (existierende) Dateien. Dazu gehören auch die folgenden zeichenorientierten Geräte: 

PRN: Parallele Schnittstelle (liefert handle -3) 

AUX: Serielle Schnittstelle (liefert handle -2) 

CON: Konsole (liefert handle -1) 

Für die wichtigsten Geräte gibt es außerdem auch schon Standardkanalnummem, so daß man 
“Fopen()” überhaupt nicht aufzurufen braucht: 

0: Tastatur (stdin) 

1: Bildschirm (stdout) 

2: Serielle Schnittstelle (stdaux) 

3: Parallele Schnittstelle (stdpm) 

Laut Atari sind die Standardkanalnummem 4 und 5 auch reserviert - wofür ist zur Zeit nicht 
bekannt. “Normale” Kanalnummern für Dateien beginnen bei 6. 


Deklaration in C: 

WORD Fopen (const char *fname, WORD mode); 


Aufruf in Assembler: 


move.w 
pea 
move.w 
trap 
addq.1 


mode, -(sp) 
fname 
#$3D, -(sp) 
#1 

#8, sp 


; Offset 6 
; Offset 2 
; Offset 0 


Parameter: 

fname: Dateiname der zu öffnenden Datei (evtl, mit Zugriffspfad, sonst wird im 

aktuellen Teilverzeichnis gesucht) 
mode: 0: nur lesen 

1: nur schreiben 

2: lesen und schreiben 

Fopen(): Entweder die Datei-Kennung (handle) oder 

EFILFN (-33): Datei nicht gefunden 
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ENHDNL (-35): keine freien Datei-Kennungen 
EACCDN (-36): Zugriff nicht erlaubt 
oder eine andere Fehlemummer 


Bemerkungen 

Unter einem GEMDOS mit File-Locking-Erweiterungen (“_FLK”-Cookie testen!) gelten 
zusätzlich folgende Definitionen: 

Der mode-Parameter ist als Bitvektor mit folgender Belegung definiert: 

Bit 7: Vererbungs-Flag 

Bit 4..6: Sharing-Modus 

Bit 3: reserviert (auf Null setzen) 

Bit 0..2: Zugriffsmodus 

Der Zugriffsmodus entspricht dem normalen Modusparameter unter Standard-GEMDOS: 

0 (binär 000): nur lesen 

1 (binär 001): nur schreiben 

2 (binär 010): lesen und schreiben 


Der Sharing-Modus legt fest, auf welche Art andere Prozesse auf die Datei zugreifen dürfen, 
wenn sie erst einmal geöffnet ist: 


0 (binär 000): 

1 (binär 001): 

2 (binär 010): 

3 (binär 011): 

4 (binär 100): 


Kompatiblitätsmodus (logischerweise der Modus, der von Programmen 
benutzt wird, die nichts von den Netzwerkerweiterungen wissen) 

Lesen und Schreiben verbieten (die Datei darf kein zweites Mal geöffnet 
werden) 

Schreiben verbieten (die Datei darf nur noch zum Lesen geöffnet 
werden) 

Lesen verbieten (die Datei darf nur noch zum Schreiben geöffnet 
werden) 

Alles ist erlaubt 


Beim zweiten Versuch, die Datei zu öffnen, wird dann überprüft, ob sich der verlangte Modus 
mit dem bereits aktiven Modus unter einen Hut bringen läßt. 

Für im Kompatibilitätsmodus geöffnete Dateien gelten folgende Regelungen: 
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- Die Datei kann anschließend nur noch vom gleichen Prozeß geöffnet werden - und auch 
nur ebenfalls wieder im Kompabilitätsmodus. 

- Die Ausnahme von der Regel: Wirdeine schreibgeschützte Datei im Kompabilitätsmodus 
zum Lesen geöffnet, dann wird automatisch Sharing-Modus 2 (“Schreiben verbieten”) 
angenommen. 

Achtung: Das File-Locking kann beratend implementiert sein (“advisory file locking”), d.h., 
daß es möglich sein kann, auf Bereiche trotz eines vorgenommenen Lockings zuzu¬ 
greifen. Programme, die File-Locking benutzen, sollten daher vor einem Zugriff 
selbst einen Lock setzen und diesen unmittelbar nach dem Zugriff wieder freige¬ 
ben. So ist garantiert, daß etwaige Locks anderer Seiten respektiert werden. 
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Fread (GEMDOS 63) - Read from file 


Liest eine bestimmte Anzahl von Bytes aus einer Datei an eine gegebene Adresse. 


Deklaration in C: 

LONG Fread (WORD handle, LONG count, void *buffer); 


Aufruf in Assembler: 

pea buffer ; Offset 8 

move.l count,-(sp) ; Offset 4 

move.w handle,-(sp) ; Offset 2 

move.w #$3F,-(sp) ; Offset 0 

trap #1 

lea $C(sp),sp 


Parameter: 

handle: Dateikennung der betreffenden Datei 

count: Anzahl der zu lesenden Bytes 

buffer: Anfangsadresse des Puffers 

Fread(): Entweder die Gesamtzahl der tatsächlich gelesenen Bytes (Vorsicht bei Über¬ 

prüfung - das ist ein LONG- Wert; 0 bedeutet Dateieende) oder 
EIHNDL (-37): Dateikennung falsch 

ELOCKED (-58): Dateiausschnitt ist blockiert 
oder eine andere Fehlermeldung 

Bemerkungen 

In GEMDOS-Versionen vor 0.15 (“Rainbow-TOS”) kommt es zum Systemhalt, wenn man 
als “count” 0 übergibt. Beim Lesen von Standardkanälen dürfen maximal 16383 Zeichen gele¬ 
sen werden. 
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Frename (GEMDOS 86) - Rename file 


Eine Datei wird umbenannt. Der neue Name darf auch einen kompletten Zugriffspfad 
innerhalb des betreffenden logischen Laufwerks enthalten - die Datei wird dann verschoben 
(“gemoved”)! 


Deklaration in C: 

WORD Frename (const char *oldname, const char *newname); 


Aufruf in Assembler: 

pea newname ; Offset 8 

pea oldname ; Offset 4 

move.w #0,-(sp) ; Offset 2 

move.w #$56,-(sp) ; Offset 0 

trap #1 

lea $C(sp),sp 


Parameter: 

Zeiger auf bisherigen Dateinamen 
Zeiger auf neuen Dateinamen (ggfs, mit Zugriffspfad) 

OK (0): alles in Ordnung 

EPTHNF (-34): Ordner nicht gefunden 

EACCDN (-36): Zugriff verwehrt (Datei schreibgeschützt) 

ENSAME (-48): nicht auf dem gleichen logischen Laufwerk 
oder eine andere Fehlermeldung 

Bemerkungen 

Ab GEMDOS 0.15 kann man mit dieser Funktion auch Ordner umbenennen (allerdings nicht 
in der Ordnerhierarchie verschieben). 

Man sollte nicht versuchen, eine Datei umzubenennen, die bereits geöffnet ist (es gelten die 
gleichen Gründe wie bei “FdeleteO”). 


oldname: 

newname: 

Frename(): 


J 
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Fseek (GEMDOS 66) - Seek file pointer 


Mit “FseekO” kann der Zeiger für Zugriffe innerhalb einer Datei neu gesetzt werden (sehr 
praktisch beispielsweise beim Überspringen von Dateiteilen). 


Deklaration in C: 

LONG Fseek (LONG offset, WORD handle, WORD seekmode); 


Aufruf in Assembler: 


move. w 
move. w 
move.1 
move.w 
trap 
lea 


seekmode,-(sp) 
handle,-(sp) 
offset,- (sp 
#$42,-(sp) 

#1 

$A(sp) , sp 


; Offset 8 
; Offset 6 
; Offset 2 
; Offset 0 


Parameter: 

offset: A nz ahl von Bytes, die übersprungen werden sollen 

handle: Dateikennung der betreffenden Datei 

seekmode: 0: positionieren ab Dateistart 

1: ab aktueller Position 

2: ab Dateiende 

Fseek(): Neue absolute Position in der Datei, oder 

EIHNDL (-37): falsche Datei-Kennung (handle) 

Bemerkungen 

Mit “FseekO” kann man auch feststellen, ob eine Ein-/Ausgabeumlenkung auf den Bildschirm 
vorliegt: 

WORD isatty (WORD handle) 

{ ■ 

LONG oldoffset, rc; 

oldoffset = Fseek (OL, handle, 1); 

rc = Fseek (1L, handle, 0); 

Fseek (oldoffset, handle, 0); 
return (rc != 1); 


1 
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Leider klappt diese Methode nicht, wenn die betreffende Datei leer ist. Dieser Fall tritt häufig 
in Shells mit Ein-/Ausgabeumlenkung (bzw. Pipes) auf. Abhilfe für die Shell: Ausgabe- 
umlenkung immer nur für nicht-leere Dateien machen. Bei Ausgabedateien immer gleich ein 
<Ctrl><Z> (End-Of-File, ASCII 26) hineinschreiben und mit “FseekO” wieder an den Datei¬ 
anfang zurückgehen. 
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Fsetdta (GEMDOS 26) -Set DTA 


Setzt die Anfangsadresse der aktuellen DTA (wird von “FsfirstO” und “Fsnextö” benutzt): 

typedef struct 
{ 


BYTE d reserved[21]; 

/* 

fürs GEMDOS reserviert */ 

BYTE d_attrib; 

/* 

Dateiattribut */ 

DWORD d__time; 

/* 

Uhrzeit */ 

UWORD d_date; 

/* 

Datum */ 

LONG d_length; 

/* 

Dateilänge */ 

char d fname[14]; 

/* 

Dateiname */ 


} DTA; 

Deklaration in C: 

void Fsetdta (DTA *ptr ); 

Aufruf in Assembler: 

pea ptr ; Offset 2 

move.w #$1A,-(sp) ; Offset 0 

trap #1 

addq.l #6,sp 


Parameter: 

ptr: Anfangsadresse der neuen DTA 

Bemerkungen 

Bei Programmstart wird die DTA ab Offset $80 (128) in der Basepage eingerichtet (das ist am 
Anfang der Kommandozeile...)! 
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Fsfirst (GEMDOS 78) - Search first 


Diese Funktion erlaubt es, Informationen über Dateien zu erfragen. Die zu übergebende Datei¬ 
spezifikation darf eine beliebige Dateibezeichnung (also mit Laufwerk oder ohne, mit absolu¬ 
tem oder relativem Pfad) enthalten. 

Je nach Wert wird dann in dem angegebenen Verzeichnis oder im aktuellen Verzeichnis ge¬ 
sucht. 

Die Dateibezeichnung darf auch einen unvollständigen Dateinamen enthalten. Als Platzhalter 
(Wildcards) kommen dabei das “?” (steht für einen beliebigen Buchstaben) und das (steht 
für mehrere beliebige Buchstaben außer dem Punkt) zum Einsatz. 

“Fsfirst()” liefert Informationen über die erste Datei, auf die das Muster paßt (Informationen 
über weitere Dateien kann man dann mit “FsnextO” erfragen). 

Einige wichtige Hinweise: 

- Wildcards dürfen nur im eigentlichen Dateinamen, nicht aber im Pfadnamen auftauchen. 

- Die GEMDOS-intemen Routinen zur Wildcard-Suche sind nicht ganz fehlerfrei (so paßt 
“A*.**” beispielsweise auf jede Datei). Im Zweifelsfall ist es sicherer, die Auswertung 
selbst zu machen und GEMDOS nach (alle Dateien) suchen zu lassen. Nicht 
umsonst verfahren die AES in der Dateiauswahlbox genauso. 

Wenn der angegebene Pfad nicht existiert, erhält man nicht etwa eine Fehlermeldung, 
sondern es werden lediglich keine Dateien gefunden. 

Das zu suchende Dateiattribut kann über “attribs” angegeben werden. Dabei werden nachein¬ 
ander folgende Regeln ausgewertet: 

1. Falls “attribs” 8 ist, erscheint die Datei nur dann, wenn ihr Attributbyte auch den Wert 
8 hat (zu deutsch: wenn man das Bit für Diskettennamen gesetzt hat, werden auch nur 
die Diskettennamen zurückgeliefert!). 

2. Wenn das Dateiattribut “Archiv” und “schreibgeschützt” enthält oder wenn es 0 ist, er¬ 
scheint die Datei. 

3. Wenn es Attributbits gibt, die sowohl im Dateiattribut als auch in “attribs” gesetzt sind, 
erscheint die Datei. 
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Das klingt nicht nur kompliziert - das ist es auch. Daher ein Blick in die C-Routine im 
GEMDOS, die für die Auswertung zuständig ist (vielen Dank an Atari für die Offenlegung 
dieser Zeilen!). Sei “da” das Dateiattribut der untersuchten Datei: 

if ( ((da ! = 0) && (attribs != 8)) || ((attribs I 0x21) & da))) 


/* Datei anzeigen */ 

} 

Folge'. Versteckte Dateien und Systemdateien werden nur dann korrekt als solche behandelt, 
wenn bei ihnen nicht das “Schreibschutz”- oder das “ Archiv”~Bit gesetzt ist (noch ein Grund, 
die Auswertung selbst vorzunehmen...). Verzeichnisse und Diskettennamen erscheinen nur 
dann, wenn auch das passende Bit in “attribs” gesetzt ist. Welche Bits muß man nun setzen, 
um alle Dateien und Ordner, nicht aber die Diskettennamen zu bekommen? Dazu nochmal 
die symbolischen Konstanten: 


#define 

FA_RDONLY 

0x01 

fdefine 

FA_HIDDEN 

0x02 

#define 

FA__SYSTEM 

0x04 

tdefine 

FA_LABEL 

0x08 

#define 

FAJDIREC 

0x10 

fdefine 

FA_ARCH 

0x20 

fdefine 

FA_ATTRIB 

(FA_DIRECIFA_RDONLY|FA HIDDENIFA SYSTEM) 


Mit “FA. ATTRIB” (0x17) als Attributmuster bekommt man also alle “interessanten” 
Dateien. Das Ergebnis wird in der DTA (“Disk Transfer Address”) abgelegt, deren Adresse 
man mit “FgetdtaO” lesen und mit “FsetdtaO” verändern kann: 


typedef struct 

{ 

BYTE d_reserved[21]; 
BYTE d_attrib; 

UWOED d_time; 

UWORD djdate; 

LONG d_length; 
char d_fname[14]; 

) DTA; 


/* fürs GEMDOS reserviert */ 
/* Dateiattribut */ 

/* Uhrzeit */ 

/* Datum */ 

/* Dateilänge */ 

/* Dateiname */ 


Deklaration in C: 

WORD Fsfirst (const char *fspec, WORD attribs); 
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Aufruf in Assembler: 

move.w attribs,-(sp) 

pea fspec 

move.w #$4E,-(sp) 

trap #1 

addq.l #8,sp 


; Offset 6 
; Offset 2 
; Offset 0 


Parameter: 

fspec: Zeiger auf den Dateinamen 

attribs: Jeweils für den gesuchten Dateityp das entsprechende Bit setzen: 

Bit 0: Datei schreibgeschützt 
Bit 1: Datei versteckt (“hidden”) 

Bit 2: Systemdatei 

Bit 3: Diskettenname (“volume name”) 

Bit 4: Teil Verzeichnis (Ordner) 

Bit 5: Archiv-Bit 

Fsfirst(): einige mögliche Return-Werte: 

OK (0): alles in Ordnung 

EFILNF (-33): Datei nicht gefunden 

ENMF1L (-49): Keine weiteren Dateien 
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Fsnext (GEMDOS 79) 

- Search next 

Setzt die mit “FsfirstO” begonnene Suche fort. 

Deklaration in C: 


WORD Fsnext (void); 


Aufruf in Assembler: 


move.w #$4F,-(sp) 

trap #1 

addq.l #2,sp 

; Offset 0 

Parameter: 


FsnextO: OK (0): 

alles in Ordnung 

ENMFIL (-49): 

Keine weiteren Dateien! 
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Fwrite (GEMDOS 64) - Write to flle 


Schreibt eine Anzahl von Bytes aus einem Puffer in eine gegebene Datei. 

Deklaration in C: 


LONG Fwrite (WORD handle, 

LONG count, void *buffer); 

Aufruf in Assembler: 


pea 

buffer 

; Offset 8 

move.1 

count, - (sp) 

; Offset 4 

move.w 

handle,-(sp) 

; Offset 2 

move.w 

#$40,-(sp) 

; Offset 0 

trap 

#1 


lea 

$C (sp), sp 


Parameter: 



handle: 

Dateikennung der betreffenden Datei 

count: 

Anzahl der zu schreibenden Bytes 

buf: 

Anfangsadresse des Puffers 

FwriteQ: 

Entweder die Gesamtzahl der tatsächlich geschriebenen Bytes (wichtig, falls 
der Platz auf der Diskette nicht gereicht hat) oder 


EACCDN (-36): 

Zugriff verwehrt (Datei schreibgeschützt?) 


EIHNDL (-37): 

Falsche Dateikennung 


ELOCKED (-58): 

Dateiausschnitt ist blockiert 


oder eine andere Fehlermeldung 
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Maddalt (GEMDOS 20) - Inform GEMDOS of “alternative” memory 


Mit diesem Aufruf (erhältlich ab GEMDOS 0.19) kann man einen Block von “Altemate 
RAM” in die GEMDOS-Speicherliste aufnehmen lassen. GEMDOS verwaltet den Block dann 
ganz so, wie alles andere “Altemate RAM”, das bereits beim Systemstart gefunden wurde. Ist 
der Block einmal installiert, kann er GEMDOS nicht wieder weggenommen werden. 

Mögliche Anwendung'. VME-Bus-Karten für den TT, deren Speicher fürGEMDOS zugänglich 
gemacht werden soll (das kann, aber muß nicht eine Speichererweiterungskarte sein: auch für 
überflüssiges RAM auf einer Grafikkarte kann das sinnvoll sein). Logischerweise darf der 
Aufruf nur einmal pro Block stattfinden (am besten also im AUTO-Ordner). 


Deklaration in C: 

LONG Maddalt (void *Start, LONG size); 


Aufruf in Assembler: 

move.l size,-(sp) 

move.1 Start,-(sp) 
move.w #$14,-(sp) 

trap #1 

lea $A(sp),sp 


Offset 6 
Offset 2 
Offset 0 


Parameter: 

Start: Anfangsadresse des Speicherbereichs 

size: Länge des Speicherbereichs 

Maddalt(): 0 (alles o.k.) oder eine Fehlermeldung 





GEMDOS 


251 


Malloc (GEMDOS 72) Allocatc memory 


Reserviert Speicherplatz oder berechnet verfügbaren Speicherplatz, 


Deklaration in C: 

void *Malloc (LONG amount); 


Aufruf in Assembler: 


move. 1 
move.w 
trap 
addq.l 


amount, - (sp) 
#$48, -(sp) 

#1 

#6, sp 


; Offset 2 
; Offset 0 


Parameter: 

amount: -1: Berechne Länge des größten verfügbaren Speicherblocks 

sonst: Anzahl der zu reservierenden Bytes (muß eine positive Zahl sein, 
ansonsten wird es zu Fehlverhalten von GEMDOS kommen!) 
Malloc(): für amount = -1: Länge des größten verfügbaren Speicherblocks 

sonst: Anfangsadresse des reservierten Speicherbereiches (oder 

im Fehlerfall 0) 


Bemerkungen 

Bei Programmstart wird der größte verfügbare Speicherblock für das gestartete Programm 
alloziert. Im Programm muß man also erst “MshrinkO” benutzen, bevor man “MallocO” 
wieder sinnvoll anwenden kann, 

GEMDOS unterstützt nur eine begrenzte Anzahl von allozierten Speicherblöcken (ausprobie¬ 
ren!). Daher sollte man diese Funktion nicht allzu häufig (etwa 30mal) innerhalb eines Pro¬ 
grammes verwenden, sondern statt dessen größere Speicherblöcke (von mindestens 16 
Kilobyte) reservieren und diese dann selbst verwalten (siehe dazu die Diskussion des GEM- 
DOS-Pools)! 

Die Speicherverwaltung wird besonders ineffektiv, wenn man viele kleinere Blöcke alloziert 
und diese dann nicht in der gleichen Reihenfolge wieder freigibt, 

“Malloc (0)” liefert vor GEMDOS 0.15 keine sinnvollen Ergebnisse, ab 0.15 wird korrekterweise 
ein Fehler gemeldet (0). 
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Man darf sich keinesfalls darauf verlassen, daß man tatsächlich soviel Bytes wie mit “Malloc 
(-1)” festgestellt allozieren kann. Insbesondere Konstruktionen wie “Malloc (Malloc (-1))” 
können ohne weiteres scheitern. 

Der Grund: Unter einem multitaskingfähigen TOS (bzw. unter einer multitaskingfähigen 
GEMDOS-Erweiterung wie “MiNT”) kann zwischen denbeiden Aufrufen ein Prozeßwechsel 
stattfinden. 

Und ein letzter Hinweis: man darf keinerlei Annahmen über Lage und Inhalt des allozierten 
Speichers machen! 

- Der Speicherblock muß nicht leer sein (siehe “Fastload”-Flag im Programmkopf). 

- Nacheinander allozierte Speicherblöcke müssen nicht unbedingt Zusammenhängen. 

- Man darf nie Speicherbereiche benutzen, die nicht dem eigenen Prozeß gehören 
(Original-Ton Atari im “Pexec Cookbook”: “Thou shalt not mess with memory thou 
ownest not”). Dies ist insbesondere in Hinsicht auf eine geplante TOS-Version mit 
Memory Protection wichtig (“Memory Protection” durch die PMMU erlaubtes, Schreib¬ 
zugriffe auf “fremden” Speicher durch eine Exception zu verhindern). 
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Mfree (GEMDOS 73) - Release memory 


Ein allozierter Speicherblock wird wieder freigegeben. 

Deklaration in C: 

WORD Mfree (void *saddr); 


Aufruf in Assembler: 

pea saddr ; Offset 2 

move.w #$49,-(sp) ; Offset 0 

trap #1 

addq.l #6,sp 

Parameter: 

saddr: Anfangsadresse des freizugebenden Speicherbereiches 

Mfree(): OK (0): alles in Ordnung 

ELMBA (-40): Falsche Speicherblockadresse (nicht mit “MallocQ” re¬ 

serviert...) 


Bemerkungen 

In den aktuell vorliegenden GEMDOS-Versionen wird nicht überprüft, ob der Speicherblock 
dem betreffenden Prozeß selbst gehört. Daher kann man theoretisch auch von anderen Prozes¬ 
sen reservierte Speicherbereiche freigeben. In Hinblick auf künftige multitaskingfähige TOS- 
Versionen ist dies aber sicherlich keine gute Idee! 





254 


ATARI Profibuch 



Mshrink (GEMDOS 74) - Shrink size of allocated block 


Verkürzt einen durch “MallocO” reservierten Speicherbereich. 

Deklaration in C: 

WORD Mshrink (void *block, LONG newsize); 

Aufruf in Assembler: 

move.l newsize,-(sp) 
pea block 

move.w #0,-(sp) 

move.w #$4A,-(sp) 

trap #1 

lea $C(sp),sp 

Parameter: 

newsize: Neue (verkürzte) Länge des Speicherblocks 

block: Anfangsadresse des zu verkürzenden Speicherblocks 

Mshrink(): einige mögliche Return-Werte: 

OK (0): alles in Ordnung 

EIMBA (-40): falsche Blockadresse 

EGSBF (-67): Speicherblock würde vergrößert 

Bemerkungen 

Üblicherweise wird beim C-Binding (zum Beispiel in “osbind.h”) der Nullparameter automa¬ 
tisch hinzugefügt, so daß man ihn beim Aufruf weglassen muß! 


; Offset 8 
; Offset 4 

; Offset 2; siehe Anmerkung 
; Offset 0 
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Mxalloc (GEMDOS 68) - Allocate memory (with preference) 


Dieser Aufruf entspricht “MallocO” (und existiert ab GEMDOS 0.19). Der einzige zusätzliche 
Parameter erlaubt die Auswahl zwischen den beiden verschiedenen RAM-Arten (siehe 
GEMDOS-Einführung): 


Modus 

Bedeutung 

0 

nur aus dem ST-RAM 

1 

nur aus dem Altemate RAM 

2 

egal, aber lieber aus dem ST-RAM 

3 

egal, aber lieber aus dem Altemate RAM 


In Modus 0 und 1 wird versucht, einen Block des verlangten Speichertyps zu allozieren. Wenn 
dazu nicht genug Speicher da ist, geht die Anforderung schief. In Modus 2 und 3 wird erst unter 
den freien Blöcken des angegebenen Typs gesucht, ansonsten aber auf die andere Speicherart 
ausgewichen. Je nach Einstellung im Programmkopf (siehe Erläuterungen zu “ph_prgflags” 
in der GEMDOS-Einführung) werden “MallocO”-Anforderungen als “Mxalloc (0,...)” (wenn 
kein Altemate RAM angefordert werden darf) oder “Mxalloc (3...)” (sonst) ausgeführt. Auch 
die Speicherplatzabfrage (mit -1L als “Länge”) erlangt dadurch eine neue Bedeutung: in den 
Modi 0 und 1 wird der größte Block der entsprechenden RAM-Art zurückgeliefert. Die beiden 
anderen Modi sind logischerweise in diesem Zusammenhang identisch und liefern den größten 
Block ungeachtet des Typus zurück. 


Deklaration in C: 

void *Mxalloc (LONG amount, WORD mode); 


Aufruf in Assembler: 

move.w mode,-(sp) ; Offset 6 

move.l amount,-(sp) ; Offset 2 

move.w #$44,-(sp) ; Offset 0 

trap #1 

addq.l #8,sp 

Parameter: 

amount: siehe “MallocO” 

mode: siehe oben 

MxallocQ: siehe “MallocO” 
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Pexec (GEMDOS 75) - Load/Execute Process 


Ermöglicht das Laden und Starten von Programmen, ohne daß das aktuelle Programm aus dem 
Speicher entfernt wird. So geladene Programme werden von den AES nicht als separate 
Applikationen angesehen! 


Deklaration in C: 

LONG Pexec (WORD mode, const char *file, const char *cmdlin, 
const char *env); 


Aufruf in Assembler: 


pea 

env 

; Offset 

pea 

cmdlin 

; Offset 

pea 

file 

; Offset 

move.w 

mode, - (sp) 

; Offset 

mo ve.w 

#$4B,-(sp) 

; Offset 

trap 

#1 


lea 

$10(sp),sp 



Parameter: 

file: Name der Programmdatei 

cmdlin: Kommandozeile für das Programm als Pascal-String: im ersten Byte steht die 

Länge der Kommandozeile, die erst ab dem zweiten Byte folgt. Die 
Maximallänge für die Kommandozeile beträgt 124 Zeichen - mit Hilfe des 
ARGV-Verfahrens kann man auch mehr Informationen übergeben. 

env: Zeiger auf das Environment. Entweder 0 - dann legt GEMDOS eine Kopie des 

aktuellen Environments an - oder ein Zeiger auf das zu übergebende 
Environment. 


Hier die verschiedenen Modi (keine Sorge, im allgemeinen ist nur Modus 0 von Interesse!): 

LOAD AND GO 


LONG Pexec (0, const char *file, const char *cmdlin, 
const char *env); 

Legt Environment und Basepage an, lädt und reloziert das in “file” angegebene Programm und 
startet es. Der Retum-Wert ist entweder ein negativer 32-Bit-Wert (wenn innerhalb von 
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“PexecO” ein Fehler aufgetreten ist) oder ein 16-Bit-Wert (der Wert, den das gestartete Pro¬ 
gramm mit “Pterm()”, “Ptermres()” bzw, “PtermOO” zurückgeliefert hat). 

Bei einem Programmabsturz werden die allseits bekannten Bomben auf dem Bildschirm 
gemalt und der Wert OxOOOOFFFF (-1 als WORD) zurückgeliefert (vor GEMDOS 0.15: 0). 

Bei einem Programmabbruch durch CTRL-C erhält man OxOOOOFFEO (also -32 als WORD) 
zurück (leider ist dies augenscheinlich nicht offiziell dokumentiert). 

Einige mögliche GEMDOS-Fehlermeldungen: 


EINVFN (-32): 
EFILNF (-33): 
ENSMEN (-39): 
EPLFMT (-66): 


Falsche Funktionsnummer 
Programm nicht gefunden 
Nicht genügend Speicher 
Keine GEMDOS-Programmdatei 


LOAD, DON’T GO 


BASEPAGE *Pexec (3, const char *file, const char *cmdlin, 
const char *env); 

Dieser Modus wird meist zum Starten von Overlays oder zum Laden von Programmen in einen 
Debugger benutzt. 

Er entspricht Modus 0, mit dem Unterschied, daß das Programm nicht sofort gestartet wird, 
sondern statt dessen ein Zeiger auf die Basepage zurückgeliefert wird. 

Wenn der so geladene Prozeß mehr als einmal gestartet werden soll, muß man folgende 
Probleme beachten: 


- Das Programm darf weder Text- noch Datensegment verändern (im Zweifelsfall sollte 
man gleich zu Beginn eine Kopie des Datensegments anlegen und vor jedem Start in das 
eigentliche Programm kopieren). 

- Das BSS-Segment muß vor jedem Start gelöscht werden. 

- Der Zustand der Standardkanäle (Ein-/Ausgabeumlenkung) wird bereits bei diesem 
Aufruf (und nicht erst beim eigentlichen Start) vererbt. 

Daher dürfen sie sich vor dem eigentlichen Aufruf mit Modus 4 oder 6 nicht mehr 
verändern (und natürlich auch nicht zwischen den Aufrufen). 
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JUST GO 

LONG Pexec (4, OL, BASEPAGE *basepage, OL); 

Startet ein bereits geladenes Programm. Die Basepage sollte mit Modus 3 oder 5 erzeugt 
worden sein. Der Retumwert entspricht dem von Modus 0. 

Dieser Modus hat ein schwerwiegendes Problem: durch einen Fehler im GEMDOS bleibt der 
aufrufende Prozeß Besitzer des durch Environment und TPA belegten Speichers. Die Folge: 
nach Rückkehr aus dem Prozeß muß man selbst für die Freigabe sorgen: 

void FreeForMode4 (BASEPAGE *child) 

{ 

Mfree (child->p_env); 

Mfree (child); 

} 

CREATE BASEPAGE 

BASEPAGE *Pexec (5, OL, const char *cmdlin, const char *env); 

Zunächst legt GEMDOS ein neues Environment an. Dann wird der größte zusammenhängen¬ 
de Speicherblock alloziert und in den ersten 256 Bytes eine Basepage angelegt. Start und 
Länge der einzelnen Programmsegmente werden noch nicht eingetragen (wie auch?). Für 
diesen Modus gibt es mehrere sinnvolle Anwendungen: einmal kann man das Programm selbst 
laden, relozieren und die fehlenden Werte in der Basepage eintragen. 

Dazu ein Beispiel: 

typedef struct 

{ 

LONG offset; /* Offset zum ersten zu relozierenden Wert */ 

BYTE info[]; /* Byte-Tabelle */ 

} RELOCINFO; 

BASEPAGE *P; 

PH *Image; /* Zeiger auf geladenes Programm */ 

LONG ProgSize; /* Länge der Programmdatei */ 

RELOCINFO *reloc; /* Zeiger auf Relozierungsinformationen */ 

LONG *toreloc; 

BYTE *info; 
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P = (BASEPAGE *)Pexec (5, OL, OL); 

/* Programm in neue TPA kopieren */ 

memcpy ((void *) ((long)P + sizeof(BASPAG)), 

(void *) ((long)Image + sizeof(PH)), ProgSize - sizeof (PH)); 

/* Basepage-Zeiger eintragen */ 

P->p_tbase = ((void *) ((long)P + sizeof(BASEPAGE))); 

P->p__dbase = ((void*) ((long)P->p_tbase + (long) Image->ph_tlen)); 
P->p_bbase - ((void *) ((long)P->p__dbase + (long)Image->ph_dlen)); 
P->p_tlen = Image~>ph_tlen; 

P~>P__dlen = Image->ph_dlen; 

P->p_blen = Image->ph_blen; 

P->p_dta = (DTA *) & (P->p_cmdlin) ; 

/* und relozieren... */ 

reloc = (RELOCINFO *)P->p_bbase; 

toreloc = (long *) ((long)P->p__tbase + reloc->offset); 
info = reloc->info; 

*toreloc += (long)P->p_tbase; 

while (*info) 

t 

BYTE offset; 
offset = *info++; 
if (offset == 1) 

toreloc = (long *) ((long)toreloc + 254L); 

eise 

{ 

toreloc = (long *) ((long)toreloc + (long)offset); 
*toreloc += (long)P->p_tbase; 


) 

/* und starten... */ 


Pexec (4, OL, P, OL); 
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Auch zum Starten eines Programms im ROM kann Modus 5 benutzt werden (genauso wird 
auch GEM gestartet). Dabei sollte man allerdings nicht vergessen, daß für die TPA der größte 
verfügbare Speicherblock alloziert wird. Sollte dies ein Problem sein (zum Beispiel weil das 
zu startende Programm keinen “MshrinkO” macht), dann muß man selbst “MshrinkO” benut¬ 
zen und den Zeiger auf das TPA-Ende entsprechend korrigieren. 

JUST GO, THEN FREE - ab GEMDOS 0.15 

LONG Pexec (6, OL, BASEPAGE *basepage, OL); 

Entspricht Modus 4, mit dem entscheidenden Unterschied, daß allozierter Speicher dem 
gestarteten Prozeß und nicht dem Starter gehört. Zusammen mit Modus 3 kann man also den 
gleichen Effekt wie durch Modus 0 erreichen. 

CREATE BASEPAGE, RESPECTING PRGFLAGS - ab GEMDOS 0.19 

LONG Pexec (7, LONG prgflags, const char *cmdlin, const char *env ); 

Wie Modus 5, nur kann in “prgflags” die gleiche Information wie im Feld “ph_prgflags” des 
Programmkopfs übergeben werden. Dieser Modus wird vom BIOS des TT benutzt, um GEM 
zu starten (GEM erhältdabei die “Erlaubnis”, Speicher aus dem Altemate RAM zu allozieren). 

Pexec() von innen 

Um zu verstehen, warum die verschiedenen Modi so und nicht anders funktionieren, ist 
folgende Übersicht des Ablaufs eines Programmstarts via Modus 0 nützlich: 

1. Programmdatei finden. 

2. Environment, TPA und Basepage anlegen: 

2a. Es wird Platz für das Environment angelegt und dieses vom Aufrufer kopiert (entweder 
dessen eigenes oder das als Parameter übergebene). 

2b. Der größte verfügbare Speicherblock wird belegt und zur TPA des neuen Prozesses. 

2c, In den ersten 256 Bytes der TPA werden erste Teile der Basepage initialisiert (ITA-, 
DTA- und Environmentzeiger). 

2d. Dateikennungen, aktuelles Laufwerk und aktuelle Verzeichnisse werden vom Aufrufer 
vererbt und in die Basepage eingetragen. 
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2e. Die Kommandozeile wird in die Basepage kopiert. 

3. Der neue Prozeß wird “Besitzer” des Environments und der TPA. 

4. Die Programmdatei wird geladen und reloziert und die Zeiger auf die Programmsegmente 
in der Basepage eingetragen. 

5. Das Programm wird gestartet: 

5a. Der Basepagezeiger “p_parent” wird gesetzt. 

5b. Am Ende der TPA wird ein Stack eingerichtet und dort die Basepageadresse abgelegt. 
5c. Der neuerzeugte Prozeß wird zum aktuellen Prozeß. 

5d. Der Prozeß wird gestartet. 

Vorsicht: Diese Information gilt nicht unbedingt für künftige GEMDOS-Versionen! 

"LOAD, DON’T GO” (Modus 3) macht die Arbeitsschritte 1, 2 und 4. Da Schritt 3 über¬ 
sprungen wurde, gehört der allozierte Speicher weiterhin dem Aufrufer. 

“JUST GO” (Modus 4) führt nur Schritt 5 aus. Da Schritt 3 vergessen wurde, gehören Environ¬ 
ment und TPA weiterhin dem aufrufenden Prozeß. Alle weiteren Speicheranforderungen 
werden dann jedoch richtig bearbeitet. 

“CREATE BASEPAGE” (Modus 5) führt einzig und allein Schritt 2 aus. 

“JUST GO, THEN FREE” (Modus 6) macht die Arbeitsschritte 3 und 5. Daher treten die Pro¬ 
bleme von Modus 4 nicht auf. 

“CREATE BASEPAGE, RESPECTING PRGFLAGS” entspricht Modus 5, nur werden zu¬ 
sätzlich die Programmflags aus dem ersten Parameter beachtet. 

Soweit die Erklärungen zu den einzelnen Modi. Daß der am häufigsten benötigte Modus 
(einfach nur ein Programm laden und starten) problemlos funktioniert, haben wir auch ge¬ 
sehen. 

Wie steht es aber mit diffizileren Wünschen? 


Problem: Programm laden, modifzieren und einmal starten. 
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Dies ist eine typische Aufgabe für einen Debugger: das zu untersuchende Programm wird 
zunächst geladen und dann modifiziert, etwa durch Setzen eines Breakpunkts. Anschließend 
soll es genau einmal gestartet werden. 

Lösung : Mit Modus 3 (LOAD, DON’T GO) laden und dann später mit Modus 6 “JUST GO, 
THEN FREE” starten. Auf GEMDOS-Versionen vor 0.15 kann man sich auch mit Modus 4 
(JUST GO) behelfen, wenn man sich abschließend selbst um die Freigabe von Environment 
und TPA kümmert. 

Problem : Programm laden und dann mehrfach starten. 

Gerade für eine Shell wäre ein solches Verfahren interessant: häufig benutzte Module werden 
nur einmal geladen und können dann immer wieder aufs neue aktiviert werden (wobei sich 
die Frage stellt, wie wichtig dies heutzutage angesichts der hohen Festplattenkapazitäten und 
-geschwindigkeiten noch ist). 

In diesem Fall würde es sich anbieten, das Programm wieder mit Modus 3 (LOAD, DON’T 
GO) einzulesen und sich dann den Fehler in Modus 4 zunutze zu machen. Probleme sind dabei 
jedoch vorprogrammiert, einige haben wir bereits bei der Erklärung von Modus 3 genannt. 

Die Idee, die Basepage nur einmal zu erzeugen und dann den Prozeß mehrmals zu aktivieren, 
führt aber noch zu weiteren Schwierigkeiten. So wird der aufgerufene Prozeß vermutlich beim 
ersten Programmstart mit “Mshrink()” den nicht benötigten Teil seiner TPA freigeben. Beim 
nächsten Ausführen legt GEMDOS jedoch den Stack wieder an der gleichen Adresse an - 
diesmal im “Niemandsland” des Speichers, denn dieser Abschnitt kann ja längst für andere 
Zwecke vergeben worden sein. Irgend jemand müßte also dafür sorgen, daß der Zeiger 
“p hitpa” in der Basepage auf das neue Ende der TPA gesetzt wird. 

Der Aufrufer ist damit allerdings überfordert - er weiß ja nicht, wie viele Bytes der TPA der 
geladene Prozeß behalten hat. Der aufgerufene Prozeß könnte das tun — nur müßte man ihn 
dafür speziell anpassen, und das ist im allgemeinen mangels Quelltext nicht möglich. 

Doch es gibt eine Lösung, die auch noch andere Probleme löst (auf die wir gleich noch zu spre¬ 
chen kommen): 

A. Programm einfach mit “Fopen()-Fread()-Fclose()” in den Speicher laden. 

B. Basepage mit Pexec-Modus 5 (CREATE BASEPAGE) erzeugen. 

C. Text- und Datensegment in die TPA kopieren, relozieren und fehlende Basepagezeiger 
setzen. 
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D. BSS löschen, 

E. Programm mittels Modus 4 bzw. 6 ausführen. 

Zur nochmaligen Ausführung können einfach die Schritte B bis E wiederholt werden. Eine 
Beispielfunktion zum Anlegen der Basepage sowie zum Relozieren und Starten des Pro¬ 
gramms haben wir bei den Erklärungen zu Modus 5 angegeben. Einziger Schönheitsfehler: 
zum Zeitpunkt der Programmausführung liegen Textsegment und Datensegment doppelt im 
Speicher, was natürlich bei langen Programmen nicht wünschenswert ist. Für Programme, die 
nicht darauf angewiesen sind, daß sie alle drei Programm Segmente in einem Stück vorfinden, 
gibt es eine elegantere Lösung: 

A. Programm einfach mit “Fopen()-Fread()-Fc!ose()” in den Speicher laden. 

B. Programmcode dort, wo er steht, relozieren. 

C. Basepage mit Pexec-Modus 5 (CREATE BASEPAGE) erzeugen. 

D. Zeiger auf Programm- und Datensegment in Basepage eintragen. 

E. BSS löschen. 

F. Programm mittels Modus 4 bzw. 6 ausführen. 

Durch Wiederholung von Schritt C bis F kann man das Programm dann ‘‘beliebig” oft starten. 

Kommen wir schließlich zu dem anderen Problem, das die Idee “einmal mit Modus 3 laden 
und immer wieder mit Modus 4 starten” zunichte macht. GEMDOS merkt sich bekanntlich 
in der Basepage einige Informationen, die beim Nachstarten von Prozessen “vererbt” werden. 
Dazu gehören beispielsweise die Zuordnungen der Standardkanäle und die aktuellen Ver¬ 
zeichnisse. 

Wie man sich denken kann, stehen in der Basepage nicht die eigentlichen Informationen, 
sondern nur Verweise auf GEMDOS-inteme Strukturen. Nehmen wir die Standardkanäle als 
Beispiel. Wenn sie auf eine “echte” Datei umgelenkt worden sind, enthält die Basepage einen 
Verweis auf einen Dateikontrollblock im Innern des GEMDOS. 

Für jeden Dateikontrollblock merkt sich GEMDOS in einem Zähler, wie “oft” die Datei 
tatsächlich geöffnet ist (fachenglisch: “usage count”). Diese Information wird benötigt, damit 
GEMDOS weiß, wie oft die Datei geschlossen werden muß, bevor der Dateikontrollblock 
wieder freigegeben werden kann. 
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Die Vererbung dieser Informationen (und damit die Erhöhung der Zähler) findet in Schritt 2 
des Pexec-Vorgangs statt. Beim Terminieren des Prozesses werden analog dazu die Zähler 
wieder vermindert. 

Und da haben (bzw. hätten) wir den Salat: die Zähler werden nur einmal erhöht, aber mehrfach 
vermindert. Die Folge wäre, daß GEMDOS-inteme Strukturen freigegeben würden, obwohl 
sie noch an anderer Stelle benötigt würden. Abstürze oder Systemhalt (“Out of internal 
memory...”) wären dann vorhersehbar. 

Aktuelle GEMDOS-Versionen (bis einschließlich 0.19) gehen also fälschlicherweise davon 
aus, daß jedes einmal geladene Programm auch genau einmal ausgeführt wird. Die Vererbung 
wird mithin zu früh gemacht - eigentlich sollte sie erst beim tatsächlichen Start des Programms 
vorgenommen werden (in Schritt 5 des Pexec-Vorgangs). 

Dies setzt voraus, daß jedes gestartete Programm früher oder später auch beendet wird (sicher¬ 
lich eine vernünftige Annahme). Atari hat angekündigt, daß künftige GEMDOS-Versionen 
exakt so arbeiten werden. 

Bemerkungen 

In älteren GEMDOS-Versionen (mindestens einschließlich 0.15) passieren unschöne Dinge, 
wenn während des Ladens der Programmdatei BIOS-Error (etwa defekte Sektoren) auftreten: 
zum Beispiel kann es leicht passieren, daß die Datei nicht wieder geschlossen wird und damit 
die Dateikennung verlorengeht. 
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PtermO (GEMDOS 0) - Terminate Process 

Ist identisch mit “Pterm(O)”. 

Deklaration in C: 

void PtermO (void); 

Aufruf in Assembler: 

clr.w -(sp) ; Offset 0 

trap #1 
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Pterm (GEMDOS 76) - Terminate process 


Der laufende Prozeß wird beendet und aus dem Speicher entfernt. Dem aufrufenden 
Programm wird der angegebene Wert als Return-Status zurückgemeldet. Das kann eine 
normale GEMDOS-Fehlermeldung oder auch ein selbstdefinierter Fehler-Code sein. 

Alle offenen Dateien (auch die Standardkanäle) werden geschlossen, und mittels “MallocO” 
oder “Mxalloc()”wird reservierter Speicher freigegeben. Bei Megas und TTs wird die Uhrzeit 
aus der Hardware-Uhr in die Systemuhr übertragen. Außerdem wird ein Sprung durch 
“etv_term” durchgeführt. 


Deklaration in C: 

void Pterm (WORD retcode); 


Aufruf in Assembler: 

move.w retcode,-(sp) ; Offset 2 

move.w #$4C,-(sp) ; Offset 0 

trap #1 

Parameter: 

retcode: Status, der an das aufrufende Programm zurückgegeben wird. Gebräuchliche 

Return-Werte sind: 

0: alles in Ordnung 

1: allgemeine Fehlermeldung 

2: Fehler in den übergebenen Parametern 

-1: sollte man nicht selbst benutzen, da dieser Wert ab GEMDOS 0.15 bei 

einem Programmabsturz zurückgeliefert wird 
-32: sollte man auch nicht selbst benutzen, da man diesen Wert bei mit 

<CtrlxC>abgebrochenen Programmen erhält 
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Ptermres (GEMDOS 49) - Terminate and stay resident 


Der laufende Prozeß wird beendet. Dabei kann man eine beliebige Anzahl von Bytes resident 
im Speicher halten (gerechnet ab Anfangsadresse der Basepage). 

Ebensowenig werden die mittels “MallocO” oder “MxallocO” allozierten Speicherbereiche 
freigegeben: im Gegenteil - sie werden vollständig aus der GEMDOS-Speicherliste entfernt 
und können nie wieder per GEMDOS benutzt werden (außer, man hängt sie wieder mittels 
“MaddaltO” in die Speicherverwaltung ein). 


Deklaration in C: 

void Ptermres (ULONG keep, WORD ret); 


Aufruf in Assembler: 

move.w ret,-(sp) 
move.l keep,-(sp) 

move.w #$31,-(sp) 

trap #1 


; Offset 6 
; Offset 2 
; Offset 0 


Parameter: 

keep: Anzahl der resident zu haltenden Bytes (ab Anfang der Basepage, mindestens 128 
Bytes) 

ret: Status, der an das aufrufende Programm zurückgegeben wird. Gebräuchliche Return- 

Werte sind: 

0: alles in Ordnung 

1: allgemeine Fehlermeldung 

2: Fehler in den übergebenen Parametern 

-1: sollte man nicht selbst benutzen, da dieser Wert ab GEMDOS 0.15 bei einem 

Programmabsturz zurückgeliefert wird 

-32: sollte man auch nicht selbst benutzen, da man diesen Wert bei mit CtrlxC> 
abgebrochenen Programmen erhält 
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Super (GEMDOS 32) - Get/Set/Inquire Supervisor mode 

Schaltet zwischen User- und Supervisor-Modus hin und her und liefert Funktionen über den 
momentanen Prozessorstatus. 

Deklaration in C: 

LONG Super (void *stack); 

Aufruf in Assembler: 

pea stack ; Offset 2 

move.w #$20,-(sp) ; Offset 0 

trap #1 

addq.1 # 6, sp 

Parameter: 

stack: 1: Es wird der momentane Prozessorstatus (0 = User-Modus, -1 = Supervisor- 

Modus) zurückgegeben. 

0: Ist der Prozessor im User-Modus, dann wird er in den Supervisor-Modus 

geschaltet und als SSP (Supervisor Stack Pointer) der bisherige USP (User 
Stack Pointer) benutzt. Zurückgeliefert wird der bisherige SSP. War der Pro¬ 
zessor zuvor im Supervisor-Modus, wild nichts Vernünftiges zurückgeliefert. 

>1: Der Prozessor-Modus wird umgeschaltet. Der Funktionswert ist der bisherige 

Wert des SSP. “stack” wird neuer aktueller Stack-Pointer. In diesem Fall sollte 
man logischerweise auf die anschließende Stack-Korrektur verzichten! 

Bemerkungen 

Zur Klärung: Man schaltet beispielsweise mittels “suret = Super (OL)” in den Supervisor- 
Modus. Am Ende des Programmteils schaltet man dann mit “Super (suret)” in den User-Modus 
zurück. 
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Sversion (GEMDOS 48) - Get version number 


Liefert Versionsnummer vom GEMDOS. Folgende GEMDOS-Versionen sind zur Zeit 
bekannt: 

0.13 (0x1300) 

Dieses GEMDOS befindet sich in TOS 1.00 und TOS 1.02 (“Blitter”-TOS). Es zeichnet sich 
durch zahllose Fehler bei der Umlenkung der Standardkanäle und durch sehr mäßige 
Arbeitsgeschwindigkeit auf Festplatten aus. 

0.14 (0x1400) 

Diese Versionsnummer trug das französische “Turbo-DOS'\ das für kurze Zeit mit Atari- 
Festplatten ausgeliefert wurde. Es war schnell und unsicher. 

0.15 (0x1500) 

Dieses GEMDOS befindet sich in TOS 1.04 und TOS 1.06. Es ist weitestgehend stabil und 
schnell. Ein bekannter Bug wird durch das offizielle Patchprogramm “POOLFIX3.PRG” 
behoben. 

0.17(0x1700) 

Ist in TOS 1.62 zu finden und unterscheidet sich von 0.15 nur dadurch, daß das Programm 
“POOLFIX3.PRG” nicht mehr benötigt wird. 

0.19 (0x1900) 

Dieses GEMDOS tauchte erstmals im TOS 3.01 des TT auf. Es wurde in erster Linie um 
Funktionen zur Verwaltung der unterschiedlichen RAM-Arten erweitert. 


Deklaration in C: 

WORD Sversion (void); 


Aufruf in Assembler: 

move.w #$30,-(sp) ; Offset 0 

trap #1 

addq.1 #2, sp 

Parameter: 

Sversion(): Low-Byte: Haupt-Revision 
High-Byte: Unter-Revision 




270 


ATARI Profibuch 


Tgetdate (GEMDOS 42) - Get date 


Das Systemdatum (GEMDOS-intem) wird abgefragt. Dabei handelt es sich um einen 
einfachen Zähler, der bei Systemstart initialisiert wird - ab TOS 1.02 bei Rechnern mit 
Hardware-Uhr mit der aktuellen Uhrzeit, sonst mit dem TOS-Erstellungsdatum (siehe 
“_sysbase”). 

Bei Rechnern mit Hardware-Uhr und ab TOS 1.02 wird zusätzlich bei jeder Beendigung eines 
GEMDOS-Prozesses die Zeit mit Hilfe der Hardware-Uhr aktualisiert. 

Auf Rechnern ohne Hardware-Uhr kann man beim Reset die GEMDOS-Uhrzeit retten, indem 
man die Zeit mittels der XBIOS-Funktionen ausliest und in die GEMDOS-Uhr überträgt. 

Deklaration in C: 

UWORD Tgetdate (void); 

Aufruf in Assembler: 

move.w #$2A,-(sp) ; Offset 0 

trap #1 

addq.l #2,sp 


Parameter: 

Tgetdate(): Aktuelles Datum 

Bit 0..4: Tag (0..31) 

Bit 5..8: Monat (1..12) 

Bit 9..15: Jahre seit 1980 (0..119) 
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Tgettime (GEMDOS 44) - Get time 


Fragt die Systemzeit der GEMDOS-intemen Uhr ab (siehe auch “TgetdateO”). 

Deklaration in C: 

UWORD Tgettime (void); 


Aufruf in Assembler: 

move.w #$2C,-(sp) ; Offset 0 

trap #1 

addq.l #2,sp 

Parameter: 

Tgettime(): Aktuelle Uhrzeit 

Bit 0..4: Sekunden (0..29) - muß verdoppelt werden 

Bit 5..10: Minuten (0..59) 

Bit 11..15: Stunden (0..23) 
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Tsetdate (GEMDOS 43) - Set date 


Setzt das Systemdatum in der GEMDOS-Uhr (ab TOS 1.02 auch in der jeweiligen Hardware- 
Uhr). 

Deklaration in C: 

WORD Tsetdate (UWORD date); 


Aufruf in Assembler: 

move.w date,-(sp) 

move.w #$2B,-(sp) 

trap #1 

addq.l #4,sp 


; Offset 2 
; Offset 0 


Parameter: 

date: aktuelles Datum (siehe unter “TgetdateO”) 

Tsetdate(): -1: Das war kein gültiges Datum 

(0<=Tag<=31, l<=Monat<=12, 0<=Jahr<=l 19)! 
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Tsettime (GEMDOS 45) - Set time 


Setzt die aktuelle Systemzeit in der GEMDOS-Uhr (ab TOS 1.02 auch in der jeweiligen Hard¬ 
ware-Uhr). 

Deklaration in C: 

WORD Tsettime (UWORD time); 


Aufruf in Assembler: 

move.w time,-(sp) ; Offset 2 

move.w #$2D,-(sp) ; Offset 0 

trap #1 

addq.l #4,sp 

Parameter: 

time: Uhrzeit (siehe “TgettimeO”) 

Tsettime(): 1: Das war keine gültige Uhrzeit 

(0<=Sekunden<=29, 0<=Minuten<=59, 0<=Stunden<=23)! 
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Kapitel 3: VDI-Betriebssystemroutinen 

Einleitung 

Das VDI (“Virtual Device Interface”) bildet die “untere” Hälfte von GEM. Genauso wie das 
BIOS den Unterbau für alle Funktionen des GEMDOS bereitstellt, ist das VDI Grundlage für 
alle AES-Funktionen. Dazu bedient es sich aller tieferliegenden Betriebssystemschichten 
(BIOS, XBIOS bis GEMDOS) und greift innerhalb der gerätespezifischen Teile naturgemäß 
auch direkt auf die Hardware zu. 

Auch wenn man mit dem VDI normalerweise primär Funktionen zur Grafikausgabe verbindet, 
erstreckt sich der Aufgabenbereich auch auf Eingaben (wie zum Beispiel per Maus oder 
Grafiktablett). Das VDI ist also eine Betriebssystemschicht zur Ansteuerung von im weitesten 
Sinn grafikorientierten Aus- und Eingabegeräten. 

Ebensowenig sollte man das Wörtchen “Virtual” übersehen. Für das Anwenderprogramm 
bedeutet dies, daß (fast) alle Funktionsaufrufe auf jedes verfügbare Ausgabegerät - ob 
Bildschirm, Plotter, Drucker oder auch Diabelichter - angewendet werden können. 

Zwei kurze Beispiele, um die Geräteunabhängigkeit des VDI zu verdeutlichen: die AES 
machen ausschließlich GEMDOS- und VDI-Aufrufe. Daher ist es möglich, die AES ohne jede 
Änderung auch auf solchen Grafikkarten einzusetzen, an deren Existenz 1984 ganz bestimmt 
noch niemand gedacht hat, zum Beispiel: 1280 * 960 Bildpunkte in 256 Farben. 

Gleiches gilt natürlich für alle sauber programmierten GEM-Anwendungen, deren Zahl in 
den letzten Jahren glücklicherweise immer stärker gewachsen ist (man denke an “SciGraph”, 
“Script 2”, “LDW-Power”, “Turbo-C” und “Gemini”). 

Bei Druckern sieht die Lage nicht anders aus: ob 9-Nadeldrucker, Tintenstrahldrucker oder 
Laserdrucker - immer kann man mit den gleichen Betriebssystemfunktionen Kreise malen 
oder Texte ausgeben. 

Die Wurzeln des VDI liegen im CP/M-GSX-System, das Anfang der achtziger Jahre aus dem 
Bedarf für eine portable Grafikschnittstelle für die damals dominierenden CP/M-Systeme 
entstand (nicht vergessen: CP/M - das erste verbreitete Betriebssystem für Mikrocomputer, 
stammte ebenfalls von Digital Research). 


Ähnlichkeiten in Funktionen und Bezeichnungen zum GKS (“Grafisches Kern-System”) sind 
keineswegs zufällig, sondern von den Entwicklern bei Digital Research voll beabsichtigt. Das 
VDI erfüllt den ANSI-Standard X3H3.6 CG-VDI! 




276 


ATARI Profibuch 


Grundlagen des VDI 

Workstations 

Fast alle VDI-Funktionen erwarten als Parameter das sogenannte “Handle” der zu benutzen¬ 
den “Workstation”. Die Parallele zu den vom GEMDOS vergebenen Datei-Handies kommt 
nicht von ungefähr, denn die dahinterstehende Idee ist eigentlich gleich. 

F ine der vielen Aufgaben einer Betriebssystemschicht ist es schließlich, den Zugriff auf die 
Hardware-Ressourcen des Rechnersystems zu verwalten. Genauso, wie zwei Programme 
nicht gleichzeitig denselben Speicherbereich benutzen oder in dieselbe Datei schreiben dür¬ 
fen, können auch die vom VDI verwalteten Ein- und Ausgabegeräte nie mehr als einem “Kun¬ 
den” gleichzeitig zu Verfügung stehen. Niemand würde erwarten, daß etwas Sinnvolles dabei 
herauskommt, wenn zwei Applikationen gleichzeitig Daten an den Drucker schicken oder 
abwechselnd Tastendrücke auslesen. 

Die Lösung'. Wer auf ein bestimmtes VDI-Gerät zugreifen will, muß dazu eine Workstation 
öffnen. Je nach Sachlage erhält man als Resultat entweder eine Fehlermeldung oder die Work¬ 
station-Kennung (Handle) des betreffenden Geräts. Anschließend darf man das angesproche¬ 
ne Gerät nach Herzenslaune benutzen. Hauptsache, man schließt die Workstation am Ende, 
um sie wieder für andere Programme verfügbar zu machen. 

Zu jeder Workstation gehört eine Menge von Merkmalen, die unveränderlich sind und über 
die Fähigkeiten des Geräts Auskunft geben. Dazu gehören neben vielen anderen Gerätetyp, 
Koordinatensystem und Farbfähigkeit. Neben den beim Öffnen der Workstation zurückgelie¬ 
ferten Daten kann man mit einer erweiterten Auskunftsfunktion noch mehr Daten abrufen. 
Dieses Informationsangebot macht es den Anwendungsprogrammen möglich, die Fähigkei¬ 
ten des Geräts optimal zu nutzen - zum Beispiel dadurch, daß sie ihren Bildschirmaufbau an 
die Anzahl der darstellbaren Bildpunkte anpassen. 

Daneben gibt es auch noch veränderliche Merkmale, die sogenannten “Attribute”. Sie 
beschreiben den aktuellen Zustand des Geräts. Ein gutes Beispiel ist die Linienfarbe, die man 
nur ein einziges Mal - und nicht etwa bei jedem einzelnen Aufruf von Zeichenfunktionen - 
setzen muß. Die aktuellen Attribute werden vom VDI in internen Strukturen für jede einzelne 
Workstation getrennt gespeichert. So kann eine Applikation unbesorgt für Bildschirm und 
Plotter getrennt verschiedene Linienfarben einstellen - das VDI erkennt jeweils am Workstation- 
Handle, wer gemeint ist. 

Der Bildschirm nimmt natürlich eine Sonderstellung ein -er muß schließlich für mehrere Pro¬ 
gramme gleichzeitig verfügbar sein. Wie sollten sonst das Fenstersystem der AES, mehrere 
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Accessories und ein Hauptprogramm gemeinsam auf dem gleichen Bildschirm ausgeben 
können? 

Das VDI bietet dazu die sogenannten “virtuellen Workstations” an, die immer nur im 
Zusammenhang mit einer bereits geöffneten “physikalischen” Bildschirm-Workstation be¬ 
nutzt werden können. Jede virtuelle Workstation verfügt über einen eigenen Satz von 
Attributen, So können mehrere Programme Workstations öffnen, ohne sich bei den Bild¬ 
schirmausgaben gegenseitig die Attribute zu verstellen. 

Doch aufgepaßt Nicht alle Eigenschaften der physikalischen Bildschirm-Workstation sind 
auf die virtuellen Workstations übertragbar. Tastatur und Maus können auch weiterhin immer 
nur von einem Programm gleichzeitig benutzt werden. Die Eingabefunktionen dürfen daher 
nur von dem Programm benutzt werden, das die physikalische Bildschirm-Workstation 
geöffnet hat. 

Normalerweise “gehört” die Bildschirm-Workstation den AES. Daraus folgt, daß man in 
normalen GEM-Anwendungen nie die VDI-Eingabefunktionen benutzen darf - die Verwal¬ 
tung von Maus und Tastatur wird vollständig von den AES (Screen-Manager) übernommen. 

Es besteht übrigens keine Verbindung zwischen den virtuellen Workstations und dem 
Fenstersystem der AES. Jede virtuelle Workstation benutzt das gleiche Koordinatensystem 
wie die zugehörige physikalische Bildschirm-Workstation. Die Koordinaten auf Positionen 
relativ zum Fensterinhalt umzurechnen ist einzig und allein Aufgabe des Anwendungspro¬ 
gramms. 

Die Verwaltung der Workstation-Attribute erfordert natürlich Speicher. Nicht nur deshalb, 
weil der Bildschirmtreiber im ROM den Speicher dynamisch (per “MallocO”) anfordert, sollte 
man nie davon ausgehen, daß das Öffnen einer physikalischen oder virtuellen Workstation 
immer klappen muß! In vielen GDOS-Versionen (siehe unten) werden die Informationen in 
statischen Strukturen verwaltet, so daß die Maximalzahl von gleichzeitig geöffneten Work¬ 
stations begrenzt ist. 


Koordinatensysteme 

Das VDI unterscheidet zwischen zwei verschiedenen Typen von Koordinatensystemen: dem 
“Rasterkoordinatensystem” (oder “RC-System”) und dem “Normalisierten Gerätekoordina¬ 
tensystem” (oder “NDC-System”, steht für “Nonnalized Device Coordinates”). 

Bei Verwendung des RC-Systems kann man exakt das dem Ausgabegerät eigene Koordinaten¬ 
system nutzen. Bei einem Bildschirm entspricht das den horizontal und vertikal verfügbaren 
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Pixeln. Der Nullpunkt liegt in der linken oberen Ecke. Hauptvorteile der Rasterkoordinaten 
sind die absolut exakte Positionierung, die die genaue Arbeit mit Bildschirmrastern (Fenster 
etc.) erst möglich macht. 

Das NDC-System hingegen hat immer eine maximale Auflösung von 32768 mal 32768 
Punkten. Das VDI rechnet beim Aufruf eines Gerätetreibers automatisch auf dessen physika¬ 
lisches Koordinatensystem um. Der Nullpunkt liegt in der linken unteren Ecke. Zur Arbeit mit 
dem NDC-System muß ein GDOS (siehe unten) installiert sein - der Bildschirmtreiber im 
ROM kann keine NDC-Koordinaten verarbeiten. 

In der Praxis wird das NDC-System nur selten benutzt. Programme, die exakte Bemaßungen 
anbieten müssen (Desktop-Publishing, wissenschaftliche Grafik) müssen intern sowieso eine 
eigene, feinere Koordinatendarstellung benutzen. 

Die Benutzung des NDC-Systems würde dazu führen, daß Koordinaten gleich zweimal kon¬ 
vertiert werden (einmal von der internen Darstellung in NDC-Koordinaten, anschließend in 
Rasterkoordinaten), was zu überflüssigen Geschwindigkeitsverlusten und Rundungsfehlem 
führt. 


NDC: 0,32767 



RC: x-1, 0 


Abb. 3.1: Das RC- und das NDC-Koordinatensysiem 
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Auflösung und Pixelgrößenverhältnis 

Im Zusammenhang mit dem Begriff “Auflösung” kommt es nur zu häufig zu Mißverständ¬ 
nissen. Viele meinen, mit der Auflösung wäre die Anzahl der verfügbaren Bildpunkte 
gemeint. Weit gefehlt! 

Die Auflösung gibt an, wie groß jeder einzelne Pixel ist. Das gebräuchliche Maß heißt “dpi”, 
was für “dots per inch”, also Pixel pro Zoll, steht (1 Zoll sind 2,54 cm). Gebräuchliche Auf¬ 
lösungen sind 


Auflösung ! 

Gerät 

72 dpi 

Macintosh-Bildschirm 

300 dpi 

Laserdrucker 

360 dpi 

24-Nadeldrucker 


Rechenexempel: Bei einem handelsüblichen Laserdrucker passen 
300 * 300 = 90000 Punkte 
auf eine Fläche von 

2,54 cm * 2,54 cm = 6,452 Quadratzentimeter. 

Das sind etwa 14000 Punkte pro Quadratzentimer. 

Ein anderes, im Druckgewerbe gebräuchliches Maß ist der “Punkt”, der 1/72 Zoll groß ist. 
Schriftgrößen werden normalerweise in “Punkt” angegeben - der Text, den Sie gerade lesen, 
ist beispielsweise in einer 10-Punkt-Schrift gesetzt. 

Wie aus der obigen Übersicht ersichtlich, ist bei einem Macintosh-Bildschirm ein Pixel genau 
einen “Punkt” groß. Eine 10-Punkt-Schrift nimmt auf dem Macintosh daher auch 10 Pixel ein. 
Diese Gleichheit vereinfacht natürlich viele Berechnungen, andererseits macht sie den Apple- 
Programmierern den Übergang zu neuen, höherauflösenden Bildschirmen sehr schwer. 

Beim VDI sieht es etwas anders aus. Die Auflösung kann beim Öffnen der Workstation 
abgefragt werden und darf für Pixelbreite und Pixelhöhe verschieden sein. 

Beim Zeichnen von Kreisen und ähnlicher geometrischer Figuren wird dieses Pixelgrößen¬ 
verhältnis (“Aspect ratio”) berücksichtigt - Kreise blieben also auch in der “mittleren” 
Auflösung des Atari ST Kreise. Als Referenzskala dient dabei die X-Achse. 
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Dieser Mechanismus erlaubt es prinzipiell, auch Geräte mit nicht-quadratischen Pixein 
korrekt anzusteuem. Hier einige weitere Beispiele: 


Auflösung 


Gerät 


360 dpi* 180dpi 
240 dpi *216 dpi 
91 dpi * 91 dpi 
91 dpi * 45 dpi 


einige 24-Nadeldrucker 
manche 9-Nadeldrucker bei Mehrfachdruck 
“ST-Hoch” auf SM 124 (640 Pixel auf 7 Zoll) 
”ST-Mittel” auf einem 12-Zoll-Farbbildschirm 


Wie man sieht, istdieAuflösungletztendlich auch von der Monitorgröße und derBildeinstellung 
abhängig. Davon weiß natürlich das VDI nichts, und so sind die beim Öffnen der Workstation 
zu ermittelnden Werte nicht zwingend exakt. Wer es ganz präzise mag, müßte sich insofern 
ein Patehprogramm im AUTO-Ordner installieren, das dem VDI korrekten Pixelgrößen 
unterschiebt. Zumindestdas Pixelgrößenverhältnis kann man jedoch den VDI-Rückgabewerten 
ziemlich verläßlich entnehmen. 


Clipping 

Clipping ist ein Verfahren, das die Benutzung eines Fenstersystems eigentlich erst möglich 
macht. Dabei gibt man mittels des Clipping-Rechtecks an, auf welchen Bildschirmbereich 
sich alle Grafikausgaben der betreffenden Workstation beziehen sollen. Alles, was aus dem 
so spezifizierten Bildausschnitt herausragt, wird bei der Bildschirmausgabe übergangen. 

Eine zwar wenig effiziente, aber leicht zu programmierende Fensterausgaberoutine würde 
einfach für jedes zu zeichnende Teilrechteck des Fensters jeweis ein Clipping-Rechteck setzen 
und dann alle zum Aufbau des Fensterinhalts notwendigen Bildschirmausgaben wiederholen. 
Wer sich die Mühe macht, zunächst anhand einer Plausibilitätabfrage festzustellen, ob das zu 
zeichnende Objekt überhaupt sichtbar ist, kann natürlich deutlich Zeit einsparen. 

Bleibt zu erwähnen, daß das Clipping natürlich nicht gratis zu haben ist. Wer optimale 
Geschwindigkeit beim Bildschirmaufbau erreichen will, sollte das Clipping-Rechteck so oft 
wie nur möglich ausschalten. 


Rasterformate 

Bei der Arbeit mit Bildschirmen spielen die Rasterfunktionen eine besonders große Rolle: sie 
sindfUralldas zuständig, was mit derBewegung oder Veränderung von Bildschirmausschnitten 
zu tun hat - als Beispiele seien das Scrolling und das Darstellen von Icons genannt. 
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Die Rasterfunktionen können ihre Aufgabe natürlich nur dann effizient erledigen, wenn als 
interne Darstellung das gleiche Format verwendet wird, wie es auch im Bildspeicher benutzt 
wird. Anderenfalls müßten die Daten bei jedem einzelnen Aufruf einer Rasterfunktion 
konvertiert werden. Naturgemäß ist jedoch der interne Aufbau des Bildspeichers von der 
Hardware des benutzten Grafiksystems abhängig - mal davon abgesehen, daß der B ildspeicher 
gar nicht unbedingt direkt für den Prozessor zugänglich sein muß. 

Wie viele Bits man pro Pixel braucht, hängt natürlich von der Anzahl der gleichzeitig dar¬ 
stellbaren Farben ab. Für monochrome Pixel braucht man jeweils nur ein Bit —man muß eben 
nur die Information “ein/aus” unterbringen. Bei 16 Farben sind es schon vier Bits (denn mit 
vier Bits kann man die Werte 0.. 15 darstellen). Diese Bits können je nach verwendeter Video¬ 
hardware völlig verschieden angeordnet sein. 

Bei einem pixelorientierten Format werden alle zu einem Pixel gehörenden Bits zusammen 
in ein oder mehrere Bytes kodiert. In einem 16-Farb-System würden also jeweils zwei Pixel 
gemeinsam in einem Byte abgespeichert; bei 256 Farben nimmt jeder Pixel ein Byte ein. 

Bei planeorientierten Formaten verfolgt man einen anderen Ansatz. Man betrachtet den 
Bildspeicher einfach als eine Sammlung monochromer (einfarbiger) Bildebenen (“planes”). 
Um zu einem Pixel die Farbe zu ermitteln, kombiniert man die zuständigen Bits aus den 
einzelnen Ebenen zu einem Farbwert. Damit ist freilich noch nichts darüber ausgesagt, wie 
die einzelnen Ebenen im Bildspeicher angeordnet sind. Eine einfache (und im PC-Bereich 
auch übliche) Lösung ist es, eine Plane nach der anderen hintereinander im Bildspeicher 
anzuordnen. 

Bei der in den bisherigen ST/TT-Modellen serienmäßig eingebauten Videohardware kommt 
eine spezielle Spielart der planeorientierten Formate zum Einsatz: die Interleaved Bitplanes. 
Die einzelnen Bildebenen sind dabei nicht jeweils am ganzen Stück nacheinander abgelegt, 
sondern wechseln sich wortweise ab (mehr dazu im Hardwareteil zum Thema “Grafiksystem”). 
Dieses Format verdankt seine Entstehung vermutlich technischen Zwängen bei der Entwick¬ 
lung der ersten STs. Daß es künftig sicherlich nicht weiterverwendet werden wird, leuchtet 
ein, wenn man sich überlegt, auf wie viele Speicherzellen im Modus “TT-Niedrig” für jeden 
einzelnen Pixel zugegriffen werden muß (Antwort: 16 Bytes). 

Doch selbst wenn es nur eine Möglichkeit zur Verwaltung der Planes gäbe, könnte daraus 
kaum ein Standardformat definiert werden. Orientierung der einzelnen Bits (steht Bit 15 für 
einen Pixel links oder rechts von Pixel 14?) und ähnliche Aspekte können prinzipbedingt bei 
jedem Grafiksystem anders gelöst sein. 

Das VDI beseitigt dieses Problem auf salomonische Art und Weise: es unterscheidet zwischen 
dem geräteahhängigen Format (das von der Hard wäre abhängt) und dem Standardformat. Das 
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Standardformat ist für alle Rechner mit VDI gleich und kann daher immer dann benutzt 
werden, wenn Rastergrafiken von “außen” in das System eingebracht werden (Beispiel: 
Darstellung von Icons in einer Resource-Datei). Zur Umwandlung zwischen beiden Formaten 
steht die Funktion “vr_tmfm()” zu Verfügung. Und hier ist die Definition des VDI- 
Standardformats: 

- Das Format ist planeorientiert. Jede Bildebene belegt ein zusammenhängendes Stück 
Speicher und hat die gleiche Anzahl von Bildpunkten. 

- Das höchste Bit eines 16-Bit-Worts steht für den am weitesten links stehenden Pixel. 

- Aufeinanderfolgende Worte im Bildspeicher bilden die einzelnen Zeilen. Das erste Wort 
einer solchen Zeile liegt am linken Bildrand. Die erste Zeile der Plane kodiert die oberste 
Pixelzeile. 



Abb. 3.2: Ein Beispiel für das geräteunabhängige Standardformat 
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In den monochromen Grafikmodi von ST und TT entspricht das geräteabhängige Format 
zufällig dem geräteunabhängigen Format, Das heißt natürlich nicht, daß man deshalb auf den 
Aufruf von “vr_tmfm()” verzichten darf! 

Über das geräteabhängige Format hingegen hat man keinerlei Informationen. Schon deshalb 
verbietet sich jede direkte Manipulation am Bildspeicher von selbst. 

Das VDI arbeitet prinzipiell Farbregister-orientiert (“Color-Lookup-Table”). Es geht also 
davon aus, daß es eine Maximalzahl von gleichzeitig darstellbaren Farben gibt und daß man 
diesen Farbregistem bestimmte - relativ frei wählbare - Farbtöne zuordnen kann. 

Diese Eigenschaft ist jedoch nicht selbstverständlich und kann auch mit Hilfe von “ vq_extnd()” 
erfragt werden. Zwei Beispiele für Grafikmodi ohne “Color-Lookup”: 

1. Der TT-Grafikmodus “TT-Hoch”: es gibt nur zwei Farbregister und zwei Farbtöne 
(Schwarz und Weiß), die auch nicht vertauscht werden können. 

2. Bei “True-Color”-Karten können “beliebig” viele Farben gleichzeitig dargestellt wer¬ 
den. Normalerweise werden 24 Bits pro Pixel benutzt - es stehen also etwa 16 Millionen 
Farben zu Verfügung. 

Bei einer derartigen Anzahl von Farbnummem hat sich die Idee von Farbregistem 
erledigt: die Anzahl der prinzipiell gleichzeitig darstellbaren Farbtöne übersteigt die 
typische Zahl von Bildpunkten bei weitem. Schon in Kürze soll das VDI solche Grafik¬ 
karten unterstützen. 

Eine weitere unbeantwortete Frage bleibt: Auf welche Weise hängen die Pixelwerte im 
Bildspeicher mit VDI-Farbnummem zusammen? 

1. Aus historischen Gründen darf man davon ausgehen, daß bei einem Pixel in VDI-Farbe 
0 (normalerweise Weiß) alle Bits gelöscht sind. Analog dazu sind bei schwarzen Bild¬ 
punkten (VDI-Farbe 1) alle Pixel gesetzt. 

Diese Regel ergibt sich schon dadurch, daß durch ein vollständiges Invertieren aller Bits 
der Pixeldarstellung Weiß und Schwarz vertauscht werden müssen, 

2. Mit“v_get_pixel()”kann man füreine gegebeneBildkoordinate sowohl VDI-Farbnummcr 
als auch Pixelwert erfragen. 

Zusätzlich haben Digital Research und Atari die Standardzuordnungen für 8- und 16-Farb- 
Grafikstufen dokumentiert (man achte speziell auf die Zuordnung von VDI-Farbe 1!). 
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Bei acht Falben; 


Pixelwert 

Farbindex 

Farbe 

Name 

000 

0 

weiß (Hintergrund) 

WHITE 

001 

2 

rot 

RED 

010 

3 

grün 

GREEN 

011 

6 

gelb 

YELLOW 

100 

4 

blau 

BLUE 

101 

7 

magenta 

MAGENTA 

110 

5 

cyan 

CYAN 

111 

1 

schwarz 

BLACK 


Bei 16 Farben: 


Pixelwert 

Farbindex 

Farbe 

Name 

0000 

0 

weiß (Hintergrund) 

WHITE 

0001 

2 

rot 

RED 

0010 

3 

grün 

GREEN 

0011 

6 

gelb 

YELLOW 

0100 

4 

blau 

BLUE 

0101 

7 

magenta 

MAGENTA 

0110 

5 

cyan 

CYAN 

0111 

8 

hellgrau 

LWHITE 

1000 

9 

dunkelgrau 

LBLACK 

1001 

10 

dunkelrot 

LRED 

1010 

11 

dunkelgrün 

LGREEN 

1011 

14 

dunkelgelb 

LYELLOW 

1100 

12 

dunkelblau 

.LBLUE 

1101 

15 

dunkelmagenta 

LMAGENTA 

1110 

13 

dunkelcyan 

LCYAN 

1111 

1 

schwarz 

BLACK 


Als Datenstruktur zur einheitlichen Beschreibung von Rastern dient die MFDB-Struktur 
(“Memory Form Definition Block”): 
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typedef struct 

{ 

void *fd_addr; /* Zeiger auf Speicherblock (muß auf gera¬ 

der Adresse liegen). Für den Bildspei¬ 
cher muß man 0 übergeben, alle anderen 
Werte werden dann ignoriert */ 

WORD fd_w; /* Breite des Speicherblocks in Punkten */ 

WORD fd_h; /* Höhe des Speicherblocks in Punkten */ 

WORD fd_wdwidth; /* Breite des Speicherblocks in 16-Bit- 

Worten */ 

WORD fd__stand; /* 0: geräteabhängiges Format, 

1: Standardformat */ 

WORD fd_nplanes; /* Anzahl der Bildebenen */ 

WORD fd_rl,fd_r2, fd_r3; /* reserviert */ 

} MFDB; 

Eine MFDB-Struktur beschreibt einen “rechteckigen” Speicherblock - entweder im 
Arbeitsspeicher oder im Bildschirm. Wenn man den Bildspeicher meint, muß man “fd_addr” 
auf 0 setzen. Alle anderen Werte werden dann ignoriert. Die VDI-Rasterfunktionen arbeiten 
ausschließlich dann mit Clipping, wenn “fd_addr” 0 ist. 

Anderenfalls beschreibt der MFDB einen für die CPU zugänglichen Speicherblock. Dann, und 
nur dann, muß man die restlichen Werte des MFDB mit sinnvollen Werten füllen. 

Die folgende Beispielfunktion ermittelt den für einen rechteckigen Bildausschnitt benötigten 
Speicherplatz und besetzt schon die wichtigsten Felder des MFDB vor; 

ULONG RastSize (WORD handle, WORD width, WORD height, MFDB *p) 

{ 

WORD work_out[57]; 

WORD widthjwd; 

vq_extnd (handle, 1, work_out); /* erweiterte Attribute 

erfragen */ 

width_wd = (width +15) / 16; /* Anzahl der benötigten 

WORDs */ 

p->fd_w = width; 
p->fd_h = height; 
p~>fd__wdwidth = v;idth_wd; 
p->fd_nplanes = work_out[4 j; 
p->fd_stand =0; 
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return (((ULONG) height) * /* Bildschirmzeilen *7 

((ULONG) widthjwd * 2) * /* Bytes pro Zeile */ 

((ULONG) work_out [4])); /* Planes */ 

} 

GDOS 

Das VDI - eine Illusion? 

Bislang wurde immer nur ganz abstrakt von “dem” VDI gesprochen. Daß die eigentliche 
Arbeit von den Gerätetreibern erledigt wird, wurde auch schon erwähnt. 

Bleibt die Frage: was bleibt vom VDI übrig, wenn man die Gerätetreiber wegnimmt? Antwort: 
es bleibt GDOS (“Graphics Device Operating System”), die Schaltzentrale, die für die 
Verwaltung der einzelnen Gerätetreiber, der nachladbaren Zeichensätze und der verschiede¬ 
nen Koordinatensysteme zuständig ist. 

Alle diese Fähigkeiten gehen dem im ROM verankerten VDI ab, weil es eben kein GDOS 
enthält. GDOS muß daher normalerweise nachträglich als residentes AUTO-Ordner-Pro- 
gramm installiert werden. 

Die Gründe hierfür sind primär in den Platzproblemen zu suchen, die Atari bei der 
Zusammenstellung der ersten TOS-ROMs plagten. Was ursprünglich als Lücke galt, darf 
heute jedoch eher als Glücksfall eingestuft werden: kaum ein anderer Betriebssystemteil hat 
von Außenstehenden soviel Weiterentwicklung erfahren - gerade deshalb , weil es so leicht 
durch eine verbesserte Version zu ersetzen ist. (Ein gutes Beispiel ist das “AMC-GDOS” von 
VDI-Insider Amd Beissner, das bis einschließlich Version 3.21 für den nichtkommerziellen 
Einsatz frei verfügbar und in fast allen Mailboxen zu finden ist.) 

Und so ist es vermutlich auch zu erklären, warum GDOS auch in den neuesten TOS - Versionen 
nicht im ROM untergebracht ist. 

Die Kehrseite der Medaille ist allerdings auch schnell beschrieben: 

- für Nicht-Insider komplizierte Installation 

- ursprünglich sehr lückenhafte Informationen 

- sehr viele ältere Programme laufen bzw. liefen nicht korrekt, wenn GDOS installiert ist 
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Ein weiterer Grund für die ursprünglich schlechte Akzeptanz von GDOS war die unüberseh¬ 
bare Bremsung aller VDI-Funktionen, die Folge einer bemerkenswert ineffizienten 
Programmierung des Dispatchers ist. GDOS-Versionen von Fremdanbietem und künftige 
GDOS-Versionen von Atari haben dieses Problem allerdings nicht mehr (oder zumindest in 
einem erheblich geringerem Maße). 

Ein anderes Problem ist natürlich die Verfügbarkeit. Wer GDOS zur Zeit in einem kommer¬ 
ziellen Programm einsetzen will, muß es mitliefem und dazu bei Atari eine Lizenz erwerben 
(gleiches gilt natürlich auch dann, wenn man das GDOS eines anderen Anbieters mitliefem 
möchte). Die von Atari geforderte Lizenzsumme ist allerdings so niedrig, daß auch kleine 
Softwarehäuser dadurch vor kein Problem gestellt werden. Genauere Informationen dazu 
erhalten Sie bei Ataris Software-Support. 


Gerätetreiber 

Jedem im System befindlichen Gerät ist ein eigener Treiber (mit einer speziellen Treiberdatei) 
zugeordnet. Der Bildschirmtreiber im ROM nimmt nur insofern eine Sonderrolle ein, als sein 
Programmcode eben im ROM und nicht in einer Datei vorliegt. 

Jeder einzelne Gerätetreiber muß alle diejenigen VDI-Funktionen übernehmen, für die nicht 
das GDOS zuständig ist, und enthält also in etwa die gleiche Funktionalität wie der ROM- 
Bildschirmtreiber. Über Aufbau und Funktionen der verschiedenen Gerätetreiber gibt ein 
eigenes Kapitel Auskunft. 


Zeichensätze 

Das VDI kennt generell zwei verschiedene Klassen von Zeichensätzen. Damit ist allerdings 
noch keine Aussage darüber gemacht, welcher Art diese Zeichensätze sind - das ist vom 
jeweiligen Treiber bzw. dem verwendeten GDOS abhängig. 

Zunächst einmal gibt es die sogenannten Systemzeichensätze - das sind solche Fonts, die das 
Gerät “von Haus aus” kennt. Den Systemzeichensatz des ROM-Bildschirmtreibers kennt 
jeder - man hat ihn permanent bei der Arbeit mit GEM vor Augen (auch, wenn es den System¬ 
zeichensatz in mehreren Größen gibt, handelt es sich doch eben nur um eine Schrift mit einer 
gemeinsamen Zeichensatznummer). Die Anzahl der verfügbaren Systemzeichensätze wird 
beim Öffnen der Workstation zurückgeliefert und muß nicht gleich 1 sein! 

Wenn GDOS installiert ist, kann man auf zusätzliche Zeichensätze zugreifen, die bei einem 
Aufruf von “vst_load_fonts()” geladen werden. Welcher Art diese Zeichensätze sind, ist nicht 
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dokumentiert und vom verwendeten GDOS abhängig. Aus der Sicht eines Anwendungs¬ 
programms verhalten sich auf jeden Fall alle verfügbaren Zeichensätze gleich. 


Koordinatensysteme 

Die Unterstützung des NDC-Koordinatensystems ist eine weitere Aufgabe von GDOS. Dazu 
merkt es sich für jede geöffnete Workstation, ob RC- oder NDC-Koordinaten benutzt werden 
sollen, und kümmert sich bei jedem VDI-Aufruf um die Konvertierung von Koordinaten und 
Maßen. 


Künftige Weiterentwicklungen 

Im PC-Bereich sind am VDI diverse Erweiterungen vorgenommen worden. Einige Beispiele: 

- Mehr Optionen beim Öffnen von Workstations (Stichwort: Papierformate bei Drucker- 
treibem). 

- Unterstützung von Grau- und Farbverläufen. 

- Bezierkurven (realisiert durch einen “globalen” Schalter, der zwischen Polyline- und 
Bezierdarstellung von Linien und Polygonen umschaltet). 

- Erweiterungen für “True-Color”-Grafik (also Farbgrafikkarten mit 24 Bit pro Pixel). 

Ob und welche dieser Erweiterungen jemals Eingang in das Atari-GDOS bzw. die Gerätetreiber 
finden wird, ist heute schwer abzusehen. Sicher scheint, daß künftige GDOS-Versionen zu¬ 
mindest PC-GEM-kompatible Beziererwciterungen enthalten werden - einige Fremdhersteller 
bieten schon jetzt solche GDOS-Versionen an (zum Beispiel: AMCGDOS 5.0). 

Von Atari seit Herbst 1990 angekündigt ist FSMGDOS , eine GDOS-Version, die PostScript¬ 
ähnliche Vektorschriften unterstützen soll. Hoffentlich ist die Entwicklung bald abgeschlos¬ 
sen, denn erst mit FSMGDOS wird das VDI die Flexibilität bei der Textausgabe haben, die 
man sich wünscht (identische Zeichensätze für alle Ausgabegeräte, freie Skalier- und Rotier- 
barkeit, ökonomischere Nutzung des Speicherplatzes). 

Keine der beiden Entwicklungen war bei Redaktionsschluß fertiggestellt und veröffentlicht. 

Daher müssen wir für weitere Informationen leider auf künftige Auflagen des Profibuchs, die 
Fachzeitschriften und den Entwickler-Support von Atari verweisen. 
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Technische Details 

Informationen über GDOS erfragen 

In einigen Fällen kann es wichtig sein, zu wissen, ob überhaupt ein vollständiges GDOS 
installiert ist (zum Beispiel, bevor man einen “vst_load_fonts()”-Aufruf macht). Glücklicher¬ 
weise hat Atari beschrieben, wie man in dieser Frage vorzugehen hat. Die Funktion beruht auf 
der Tatsache, daß der Trap-Dispatcher den Eingabewert -2 für Register DO genau dann 
verändert, wenn ein GDOS installiert ist ( Vorsicht: Die GEM-Versionen des niederländischen 
Softwarehauses “ABC” (ABC-GEM 2.x) stürzen bei diesem Aufruf ab). 

Bei den meisten Entwicklungssystemen ist diese Funktion bereits in die VDl-Bibliotheken 
aufgenommen worden. Hier ein Beispiel-Binding in Alcyon-C: 

/* liefert 0, falls GDOS nicht installiert ist */ 


WORD vq gdos() 

1 

asm(" move.w 

#-2,d0 


asm(" 

trap 

#2 


asm(" 

cmp.w 

#-2,dO 


asm(" 

sne 

dO 


asm(" 

ext .w 

dO 



1 


Zeichensatzformat 

Alle zur Zeit erhältlichen GDOS-Versionen können Zeichensätze im DR-Standardformat für 
Bitmap-Zeichensätze laden. Bei diesem Format wird der Zeichensatz einfach wie ein sehr 
breites monochromes Rasterbild organisiert - alle Zeichen stehen in Reih und Glied neben¬ 
einander. Die Breite des Rasters (“form width”) ist die Summe aller Zeichenbreiten, die 
Rasterhöhe (“form height”) entspricht der Höhe eines einzelnen Zeichens. 

Unmittelbare Konsequenz : Der linke Rand eines Zeichens fällt nicht unbedingt auf eine 
Bytegrenze! Nur am Ende jeder Rasterzeile wird mit Nullbits soweit aufgefüllt, bis der nächste 
Zeilenbeginn wieder auf eine Wortgrenze fällt. 

Da das VDI ursprünglich auf dem PC entwickelt wurde, liegen normalerweise alle Daten im 
Intel -Format vor. Es müssen also in jedem einzelnen 16-B it-Wort des Zeichensatzkopfes das 
obere und das untere Byte vertauscht werden. 
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Auch ein Motorola-Format (ohne Bytevertauschung) ist definiert und kann anhand eines Flags 
im Dateikopf unterschieden werden. Zeichensätze im Motorola-Format werden zwar ROM- 
intem für die Systemzeichensätze benutzt, können aber von den meisten GDOS-Versionen 
nicht gelesen werden. Der Dateiheader für einen solchen Zeichensatz sieht wie folgt aus: 


typedef struct 

{ 

WORD 

WORD 

CHAR 

DWORD 


UWORD 

UWORD 

UWORD 

UWORD 

UWORD 

UWORD 

UWORD 

UWORD 

UWORD 

UWORD 

UWORD 


UWORD 

UWORD 


UWORD 


UWORD 


font_id; 
point; 
name[32]; 
first ade; 


last_ade; 

top; 

ascent; 

half ; 

descent; 

bottom; 

max char width; 


/* Fontnummer */ 

/* Größe im Punktmaß */ 

/* Name des Zeichensatzes */ 

/* Erstes Zeichen im Zeichensatz (nur 
die wenigsten DruckerSchriften 
enthalten Control-Zeichen, also 
ASCII-Werte kleiner 32) */ 

/* Letztes Seichen im Zeichensatz */ 
/* Abstand Topline<->Baseline */ 

/* Abstand Ascentline<->Baseline */ 

/* Abstand Halfline<->Baseline */ 

/* Abstand Descentline<->Baseline */ 
/* Abstand Bottomline<->Baseline */ 


/* größte Zeichenbreite */ 


max_cell_width; 

/* größte Zeichenzellenbreite */ 
left offset; /* linker Offset für Kursivschrift */ 
right_offset; /* rechter Offset für Kursivschr. */ 
thicken; /* Verbreiterungsfaktor für 

Fettschrift (bei Fettschrift wird 
die Breite um genausoviele Pixel 
erhöht) */ 


ul_size; 

lighten; 


skew; 


flags; 


/* Dicke der Unterstreichung */ 

/* Maske für helle Schrift (wird mit 
Raster undiert, normalerweise 
0 x 5555) */ 

/* Maske für Kursivschrift (be¬ 
schreibt, an welchen Stellen die 
Rasterzeilen verschoben werden 
sollen, normalerweise 0 x 5555 */ 
/* Bit 0: gesetzt, wenn es der 

"Default System font" ist 
Bit 1: gesetzt, wenn die "Hori- 
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UBYTE 

*hor_table; 

/* 

UWORD 

*off_table; 

/* 

UWORD 

*dat_table; 

/* 

UWORD 

form width; 

/* 

UWORD 

form_height; 

/* 

FONT_HDR 

*next font; 

/* 


} FONT HDR; 


zontal offset table" 
benutzt wird 

Bit 2: gesetzt, wenn Bytes nicht 
vertauscht werden müssen 
(Motorola-Format) 

Bit 3: gesetzt, wenn der Font 

nicht proportional ist */ 
Zeiger auf "Horizontal Offset 
Table"; in der Datei der Offset 
zum Dateibeginn */ 

Zeiger auf "Character Offset 
Table" */ 

Zeiger auf Fontimage */ 

Breite des Zeichensatzimage */ 

Höhe des Zeichensatzimage *J 
Zeiger auf nächsten Fontheader (in 
Fontdatei zunächst unbenutzt) V 


Bleibt ein Problem'. Um das Motorola/Intel-Flag abfragen zu können, muß man eigentlich 
bereits wissen, welches Format der Zeichensatz hat (denn im Intel-Format liegen alle 16-Bit- 
Worte des Headers “vertauscht” vor!). Einzige Möglichkeit: Man geht davon aus, daß Bit 10 
des Flags niemals benutzt sein wird und testet, ob Bit 2 im 67. Byte des Headers gesetzt ist 
- dann hegt der Font im Motorola-Format vor! 


Die “Character Offset Table” ist eine Tabelle von 16-Bit-Werten, die den horizontalen 
Pixeloffset für jedes Zeichen innerhalb des Fontrasters angibt. 

Als Index muß man also den ACSII-Code minus den ACSÜ-Code des ersten Zeichens im 
Zeichensatz benutzen (“first_ade”). Die Breite eines Zeichens ergibt sich aus der Differenz 
zum Offsetwert des nächsthöheren Zeichens (damit diese Formel auch für das letzte Zeichen 
funktioniert, enthält die Tabelle immer einen Eintrag mehr, als Zeichen da sind). 


Die “Horizontal Offset Table” wird nur bei wenigen Zeichensätzen benutzt und enthält positve 
oder negative Offsetwerte, die vor der Ausgabe eines Zeichens auf die X-Position addiert 
werden. 


Abschließend sei nochmals darauf hingewiesen, daß sich eine normale VDI-Anwendung 
niemals mit diesem Format befassen muß. Die Beschreibung ist nur für diejenigen wichtig, 
die Zeichensatzeditoren oder -generatoren entwickeln oder die Welt mit einer weiteren neuen 
GDOS-Version beglücken wollen. 
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Zeichensatznamen 

Atari selbst liefert auf der GDOS-Systemdiskette folgende Zeichensätze mit: 


Fontnummer 


Name 


02 

14 

15 


Swiss (Helvetica-Schrift, Dateien “ATSS*.FNT”) 
Dutch (Times-Schrift, Dateien “ATTR*.FNT”) 
Typewriter (Courier-Schrift, Dateien “ATTP*.FNT”) 


Auch die Bedeutung der Dateinamen ist dokumentiert, wird aber leider nicht einheitlich 
benutzt: 


Zeichen 


Belegung 


0..1 

2.. 3 

4.. 5 

6 .. 7 


Hersteller des Zeichensatzes (bei Ataris Zeichensätzen “AT”) 

Kürzel für den Zeichensatztyp (z. B. “SS” für “Sans Serif’, “TR” für 
‘Times Roman”, “TP” für “Typewriter”) 

Punktgröße des Zeichensatzes 

Typ des Ausgabegeräts (z. B. “EP” für Epson-9-Nadeldrucker, “LS” für 
Laserdrucker, “CG” für die 640*200-Auflösung oder leer für Standard- 
Bildschirmfonts) 


Die ASSIGN.SYS-Datei 

DieseTextdateienthältlnformationen über die vorhandenen Gerätetreiberund die Zeichensätze, 
die ihnen zugeordnet sind. GDOS sucht sie bei Systemstart im Wurzelverzeichnis des Boot¬ 
laufwerks. 

Hier zunächst eine Beispieldatei: 

; Beispiel für ASSIGN.SYS-Datei 
path = C:\gemsys 

01p screen.sys ; Bildschirmtreiber (ROM) 

ATSS10.FNT 

ATSS12.FNT 

ATSS18.FNT 

ATSS24.FNT 

ATTR10.FNT 
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ATTR12.FNT 
ÄTTR18.FNT 
ATTR24.FNT 
ATTP10.FNT 

02p screen.sys ; Bildschirmtreiber (ROM) 

ATSS10.FNT 
ATSS12.FNT 
ATSS18.FNT 
ATSS24.FNT 
ATTR10.FNT 
ATTR12.FNT 
ATTR18.FNT 
ATTR24.FNT 
ATTP10.FNT 

03p screen.sys ; Bildschirmtreiber (ROM) 

ATSS10CG.FNT 
ATSS12CG.FNT 
ATSS18CG.FNT 
ATSS24CG.FNT 
ATTR10CG-FNT 
ATTR12CG.FNT 
ATTR18CG.FNT 
ATTR2 4 CG.FNT 
ATTP10CG.FNT 
ATTP10CG.FNT 

04p screen.sys ; Bildschirmtreiber (ROM) 

ATSS10.FNT 
ATSS12.FNT 
ATSS18.FNT 
ATSS24.FNT 
ATTR10.FNT 
ATTR12.FNT 
ATTR18.FNT 
ATTR24.FNT 
ATTP10.FNT 
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21r fx80.sys ; Epson FX80, resident 


ATSS10EP.FNT 
ATSS12EP.FNT 
ATSS18EP.FNT 
ATSS24EP.FNT 
ATTR10EP.FNT 
ATTR12EP.FNT 
ATTR18EP.FNT 
ATTR24EP.FNT 
ATTP10EP.FNT 


31 meta.sys ; Metafile-Treiber 

ATSS10MF.FNT 
ATSS12MF.FNT 
ATSS18MF.FNT 
ATSS24MF.FNT 
ATTR10MF.FNT 
ATTR12MF.FNT 
ATTR18MF.FNT 
ATTR24MF.FNT 
ATTP10MF.FNT 

Kommentare werden mit einem Semikolon eingeleitet und können an einer beliebigen Stelle 
in der Textzeile beginnen - auf einem Atari TT würden noch zusätzliche Einträge für die 
Geräte 5 bis 10 benötigt. Die erste Zeile, die keinen Kommentar enthält, darf einen Eintrag 
der Form 

path = pfadname 

enthalten. 

GDOS sucht dann Treiber und Zeichensätze in dem dort angegebenen Verzeichnis (Maximal¬ 
länge: 64 Zeichen!). 

Es folgen die Einträge für die Gerätetreiber und die ihnen zugeordneten Zeichensätze. 
Jeder Gerätetreiberformat hat das Format: 


<Nummer><Flag> <Dateiname des Treibers> 



VDI-Betriebssystemroutinen 


295 


Die Nummer entspricht der beim Öffnen der Workstation übergebenen Gerätenummer. Man 
beachte, daß für jede mögliche Gerätenummer auch ein Treiber angemeldet sein muß. Die 
AES benutzen zur Berechnung der zu benutzenden Bildschirmworkstation die Formel: 

2 + Getrez () ; 

Als Flag darf “r” (Treiber gleich beim Booten resident laden) oder “p” (Treiber ist im ROM 
installiert) oder auch nichts (Treiber beim Öffnen der Workstation nachladen) angegeben 
werden. Bei gesetztem “p”-Flag ist der Treibemame nur ein Platzhalter, den GDOS braucht, 
um die Zeile dekodieren zu können. 

Es folgen die Einträge für die einzelnen verfügbaren Zeichensätze. Man beachte dabei, daß 
Fonts der gleichen Familie (also mit gleicher Fontnummer, aber verschiedener Punktgröße) 
direkt aufeinander folgen sollten. 


Übersicht über die VDI-Bibliotheken 

Die VDI-Funktionen sind in sieben Bereiche unterteilt. Diese Unterteilung ist nicht immer 
ganz konsequent - aus historischen Gründen wollen wir es aber dabei belassen. Der Meinung, 
die von Digital Research vergebenen Bezeichnungen seien allzu kryptisch, können wir uns 
nicht anschließen, man muß sich eben nur an sie gewöhnen. 

Im allgemeinen kann man nämlich aus den Buchstaben vor dem ersten Unterstrich schon die 
Funktion gut einordnen. Beispiel: “vst_” steht für “VDI SET TEXT”. 

Kontrollfunktionen 

Diese Funktionen dienen zur Kontrolle der Workstations - Öffnen und Schließen, Laden und 
Freigeben von Zeichensätzen, Setzen des Clippings und verwandte Informationen. Faustregel: 
Bei den meisten dieser Funktionen spielt GDOS eine Rolle. 

Ausgabefunktionen 

Mit Hilfe dieser Funktionen werden die Grafikgrundformen ausgegeben. 

Attributfunktionen 

Jede Grafikgrundform ist in verschiedenen Darstellungen verfügbar. Man kann mit den Attri¬ 
butfunktionen Farbe, Linienbreite und vieles mehr wählen. Mehrere Attributfunktionen kön¬ 
nen zu Füll-, Linien-, Marker- und Text-Attributen zusammengefaßt werden. 
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Raster-Operationen 

Die Raster-Operationen bieten die Möglichkeit, Raster unter Anwendung verschiedener 
Verknüpfungen im Bildspeicher, im Arbeitsspeicher oder zwischen beiden Bereichen hin und 
her zu kopieren. Ferner können Raster konvertiert und die Belegung einzelner Pixel abgefragt 
werden. 

Eingabefunktionen 

Mit diesen Funktionen können die verschiedenen Eingabegeräte (wie Maus oder Tastatur) 
abgefragt werden. Die Eingabefunktionen sind zwar ein Bestandteil des Bildschirmtreibers, 
dürfen aber nur auf der physikalischen Workstation eingesetzt werden. 

Eine Eigenheit der Eingabefunktionen sind die “doppelten” Bindings für viele Funktionen: 
Je nach eingeschalteter Betriebsart (Request oder Sample) werden unterschiedliche Funk¬ 
tionsnamen benutzt - auch wenn der benutzte Opcode gleich ist. 

Auskunftsfunktionen 

Mit diesen Funktionen kann man jederzeit gesetzte Attribute oder andere Parameter abfragen. 
Escapes 

Spezielle Fähigkeiten des Grafikgerätes können mit diesen Funktionen ausgenutzt werden. 
Auf dem Textbildschirm etwa kann man mit den Escape-Funktionen eine Hardcopy auslösen, 


VDI-Bindings 


Der VDI-Parameterblock 

Das VDI benutzt zur Parameterübergabe nicht die Prozessorregister oder den Stack, sondern 
mehrere Ein- und Ausgabefelder. Im einzelnen sind das: 

WORD contrl[12]; 

Dieses Feld enthält folgende Eingabeparameter: 

contrl[0]: Opcode derFunktion {Vorsicht', kann sich überden ganzen Bereich von-32768 

bis 32767 erstrecken!) 
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contrl[l]: Anzahl der Eingabekoordinatenpaare 

contrl[3J: Anzahl der Werte im intin-Array 

contrl[5]: Identifikationsnummer für Unter-Opcode 

contrl[6]: Workstation-Handle 

contrl[7..]: Mögliche weitere Werte, abhängig von der Funktion 

Zurück erhält man folgende Rückgabewerte: 

contrl[2]: Anzahl der Ausgabekoordinatenpaare 

contrl[4]: Anzahl der Werte im intout-Array 

contrl[6]: Workstation-Handle (beim Öffnen der Workstation) 

contrl[7..]: Mögliche weitere Werte, abhängig von der Funktion 

WORD intin [...]; 

WORD intout 

Diese beiden Felder enthalten Ein- bzw. Ausgabeparameter - und zwar alle die, die keine 
Maße oder Koordinaten beschreiben. Auch einzelne Zeichen und Zeichenketten werden hier 
übergeben (indem die einzelnen Zeichen auf 16-Bit-Werte expandiert werden). Wie viele 
Werte maximal übergeben werden können, hängt vom jeweiligen Treiber ab und kann mit 
“vq_extnd()” erfragt werden. 

WORD ptsin 
WORD ptsout[...]; 

Diese beiden Felder enthalten alle Parameter, die Maß- oder Koordinatencharakter haben. Sie 
werden deshalb unabhängig von “normalen” Parametern geführt, weil bei ihnen gegebenfalls 
die Koordinatentransformation zwischen NDC- und RC-System durchgeführt werden muß. 
Die maximal zu übergebende Anzahl von Koordinatenpunkten ist nicht nur von wissenschaft¬ 
licher Bedeutung, sondern legt die maximale Punktzahl für Linienzüge und Polygone fest. 
Wie viele Koordinatenpunkte (also Wortpaare!) übergeben werden können, läßt sich mittels 
“vq_extnd()” erfragen. Die Adressen der fünf Parameterfelder werden als Zeiger im VDI- 
Parameterblock abgelegt: 


Adresse 

Inhalt 

PB 

Adresse des contrl-Arrays 

PB+4 

Adresse des intin-Arrays 

PB+8 

Adresse des ptsin-Arrays 

PB+12 

Adresse des intout-Arrays 

PB+16 

Adresse des ptsout-Arrays 
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Der VDI-Trap 

Zum Aufruf einer VDI-Funktion lädt man Datenregister DO mit der Konstante 115, Dl mit 
der Anfangsadresse des VDI-Parameterblocks und macht einen “TRAP #2”-Aufruf. Darüber, 
welche Register verändert werden, gibt es keine klaren Informationen. Tatsache aber ist, daß 
die entsprechenden Routinen im ROM alle Register retten. 

Leider gibt es keinen dokumentierten Retum-Code für “Unbekannte Funktionsnummer”. Im 
Zweifelsfall muß man sich also folgendermaßen behelfen: 

1. Die “Extended Inquire Function” bietet bereits etliche Infonnationen über den angespro¬ 
chenen Treiber an. 

2. Ansonsten muß man den fraglichen VDI- Aufruf ausprobieren und dann die Rückgabewerte 
analysieren. Viele Funktionen liefern als Resultat den eingestellten Wert zurück. 
Daneben kann man auch untersuchen, ob contrl[2] und contrl[4] die korrekten Zahlen 
enthalten. 


Hier noch eine Übersicht über die möglichen Opcodes (also Werte für DO.W), die vom 
Dispatcher verstanden werden: 


Opcode 

Funktion 

-2 

Abfrage, ob GDOS vorhanden ist 

-1 

Nicht dokumentiert, aber vom GDOS benötigt: bei diesem Aufruf liefert der 
ROM-Bildschirmtreiber die Adresse einer Funktion zurück, die das GDOS 
dann - ganz wie bei einem “normalen” Bildschirmtreiber - per JSR aufru- 
fen kann. 

Wer sich in den VDI-Trap einklinken will, muß auch diese Funktionsnum¬ 
mer abfangen, damit ein eventuell später installiertes GDOS wie beabsich¬ 
tigt funktioniert. 

115 

VDI-Aufruf 

200 

AES-Aufruf 


Die Beispiel-Bindings 

Bei den hier vorliegenden Beispiel-Bindings des Alcyon-Compilers hat man es sich recht 
einfach gemacht und den Parameterblock kurzerhand folgendermaßen deklariert: 

int *pooff,*iooff,*pioff,*iioff,*pblock; 
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Daß ein C-Compiler diese fünf Pointer direkt hintereinander im Speicher anlegt, ist nicht 
überraschend. Daß bei dieser Deklaration aber auch noch die richtige (nämlich umgekehrte) 
Reihenfolge herauskommt, dürfte ein implementationsabhängiger Zufall sein - dieser 
Programmierstil ist also nicht zur Nachahmung empfohlen! 

Was noch fehlt, ist die Initialisierung des Parameter-Blocks. Die letzten vier Adressen werden 
von “OPEN WORKSTATION” bzw. “OPEN VIRTUAL WORKSTATION” eingesetzt, 
während die Funktion “vdi()” den ersten Wert setzt (nämlich “pblock”, der den Zeiger auf das 
contrl-Array enthält). 

Die Funktion “vdi ()” hat eine vergleichsweise einfache Aufgabe: 

- Die Adreßregister AO und Al werden gerettet. 

- Die Anfangsadresse des contrl-Arrays wird in “pblock” eingetragen. 

- Die Adresse von “pblock” (also die Anfangsadresse des VDI-Parameterblocks) wird in 
Datenregister Dl geladen. 

- Datenregister DO wird mit der Zahl “115” geladen. 

Abschließend wird über “TRAP #2” GEM aufgerufen, und es werden noch die beiden 
zuvor geretteten Adreßregister wiederhergestellt. 

Kein Teil des ST/TT-Betriebssystems ohne Ausnahmen: einige wenige Funktionen erwarten 
oder liefern 32-Bit-Werte. Da alle Ein- und Ausgabefelder jeweils nur 16-Bit-Wort-Felder 
sind, muß man mit einem Kunstgriff die Werte auf zwei 16-Bit-Variablen verteilen. Dazu 
werden hier die Funktionen “i_ptr” (schreibt den angegebenen Wert in contrl[7] und 
contrl[8]), “i_ptr2” (dasselbe mit contrl[9] und contrl[10]), sowie “m_lptr2” (überträgt 
contrl[9] und contrl[10] in die angegebene Adresse) benutzt. 


VDI-Gerätetreiber 

Einleitung 

Ein Gerätetreiber ist eine völlig normale Programmdatei ohne STARTUP-Code (z,B. Spei¬ 
cherreservierung), die als erste Routine jm Textsegment (also an der “Einsprungadresse”) 
einen “Dispatcher” für die eingehenden VDI-Aufrufe enthält: 
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- Die Adresse des VDI-Parameterblocks wird in Register Dl übergeben. 

- Die Funktion wird mit einer RTS-Instruktion abgeschlossen. 

Folgendes muß man noch bei der Implementation eines Gerätetreibers beachten: Nicht alle 
Funktionen erreichen den eigentlichen Treiber genauso, wie sie abgesandt werden, sondern 
sie werden vom GDOS “vorverarbeitet”. Im einzelnen sind dies: 

- Das Laden der Zeichensätze. GDOS lädt alle in der ASSIGN.SYS-Datei angegebenen 
Zeichensätze (sofern der Speicher reicht), “reloziert” die einzelnen Zeiger und verkettet 
alle Header über das “next_font”-Feld zu einer linearen Liste. Der Treiber erhält diese 
vorverarbeiteten Zeichensätze im Rahmen eines “ vst_load_fonts()”-Aufrufs mit der fol¬ 
genden, vom normalen Gebrauch abweichenden Parameterbelegung: 

contrl[7/8] Adresse des “Scratch”-Puffers zur Berechnung von Texteffekten 
(wie kursiv oder fett). 

contrl[9] Länge dieses Puffers in 16-Bit-Worten. 

contrl[10/l 1] Anfangsadresse des ersten Fontheaders in der Zeichensatzliste. 

Dieses Interface zum Laden der Zeichensätze funktioniert also ausschließlich dann, 
wenn GDOS nicht installiert ist! 

Der Treiber arbeitet immer im Rasterkoordinatensystem. Die Konvertierung der Werte 
im ptsin- und ptsout-Feld wird vom GDOS übernommen. 


Bildschirmtreiber 

Besonderheiten 

Bei den aktuellen TOS-Versionen findet sich der VDI-Bildschirmtreiber im ROM, kann aber 
durch einen vom GDOS nachzuladenden Treiber ersetzt werden. 

Derartige Treiber existieren mittlerweile für diverse Grafikkarten, beispielsweise die des 
Herstellers “Matrix”. Man beachte, daß bei einigen auf dem Markt befindlichen Treibern 
Funktionen fehlerhaft implementiert sind bzw. ganz fehlen. 

( Hinweis : Erkundigen Sie sich vor einer eventuellen Anschaffung nach der vollen Unterstüt¬ 
zung von GEM-Zeichensätzen.) 
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Der ROM-Bildschirmtreiber selbst weist folgende Merkmale auf: 

- Die zu “CELL ARRAY” gehörigen Funktionen sind nicht implementiert (sind laut 
Digital Research aber auch optional). 

- Einige der Eingabefunktionen arbeiten nicht fehlerfrei (was keine schlimme Einschrän¬ 
kung ist, da sie von den AES nicht benötigt werden). 

- Das ROM-VDI basiert auf dem Kern der sogenannten “Line-A”-Funktionen, über die 
das VDI sämtliche Ausgaben abwickelt (mehr dazu später). 

- Die Escape-Routinen zur Bildschirmausgabe sind mit den vom BIOS für “CON:” und 
“RAWCON:” benutzten Routinen identisch (können allerdings nicht wie ihre ihreBIOS- 
Gegenstucke “umgelenkt” werden). 

Mindestfunktionsumfang 

(Spezifikation nach Atari, “GEM Programmerks Guide”) 


Opcode 

Funktion 

1 

Open Workstation 

2 

Close Workstation 

3 

Clear Workstation 

4 

Update Workstation 

5 

Escape-functions 

1 

Inquire addressable character cells 

2 

Exit alpha mode 

3 

Enter alpha mode 

4 

Cursor up 

5 

Cursor down 

6 

Cursor right 

7 

Cursor left 

8 

Home Cursor 

9 

Erase to end of screen 

10 

Erase to end of line 

11 

Direct Cursor address 

12 

Output Cursor addressable text 

15 

Inquire current alpha Cursor address 

18 

Place graphic Cursor 

19 

Remove last graphic Cursor 
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Opcode 

Funktion 

6 

Polyline 

7 

Polymarker 

8 

Text 

9 

Filled area 

11 

Generalized Drawing Primitive (GDP) 

1 

Bar 

2 

Are 

3 

Pie 

4 

Circle 

5 

Ellipse 

6 

Elliptical arc 

7 

Elliptical pie 

8 

Rounded rectangle 

9 

Filled rounded rectangle 

10 

Justified graphics text 

12 

Set character height, absolute mode 

14 

Set color representation 

15 

Set polyline Iinetype 

17 

Set polyline color index 

18 

Set polymarker type 

20 

Set polymarker color index 

21 

Set text face 

22 

Set graphic text color index 

23 

Set fill interior style 

24 

Set fill style index 

25 

Set fill color index 

26 

Inquire color representation 

28 

Input locator 

33 

Input string 

32 

Set writing mode 

33 

Set input mode 

35 

Inquire current polyline attributes 

36 

Inquire current polymarker attributes 

37 

Inquire current fill area attributes 

38 

Inquire current graphic text attributes 

39 

Set graphic text alignment 

100 

Open virtual screen Workstation 

101 

Close virtual screen Workstation 

102 

Extended inquire function 
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Opcode 

Funktion 

104 

Set fill perimeter visibility 

106 

Set graphic text special effects 

107 

Set character cell height, points mode 

108 

Set polyline end styles 

109 

Copy raster, opaque 

110 

Transform form 

111 

Set mouse form 

112 

Set user-defined fill pattem 

113 

Set user-defined linestyle 

114 

Fill rectangle 

115 

Inquire input mode 

116 

Inquire text extent 

117 

Inquire character cell width 

118 

Exchange timer interrupt vector 

121 

Copy raster, transparent 

122 

Show Cursor 

123 

Hide Cursor 

124 

Sample mouse button state 

125 

Exchange button change vector 

126 

Exchange mouse movement vector 

127 

Exchange Cursor change vector 

128 

Sample keyboard state information 

129 

Set clipping rectangle 

130 

Inquire face name and index 

131 

Inquire current face information 


Im aktuellen ROM-Bildschirmtreiber zusätzlich implementiert: 


Opcode 

Funktion 

13 

Set character baseline vector 

16 

Set polyline width 

19 

Set polymarker height 

30 

Input choice (fehlerhaft) 

103 

Contour fill 

105 

Get pixel 

119 

Load fonts 

120 

Unload fonts 
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Line-A-Routinen 

Der “harte Kern” des ROM-Bildschirmtreibers ist der sogenannte Line-A-Emulator. Diese 
Bezeichnung ist allerdings etwas irreführend, da es auf Anhieb nicht unbedingt klar ist, was 
denn überhaupt emuliert wird... Was macht die CPU des ST, wenn sie auf einen unbekannten 
Befehl trifft? 

Nun, sie löst einen TRAP (Nummer 4, “illegaler Befehl”) aus, den der verwirrte Benutzer auf 
dem Bildschirm durch vier Bömbchen erkennen kann. Eine Ausnahme bilden jedoch die 
Opcodes, deren oberste vier Bits ein “$A" oder ein “$F” darstellen. Läuft die CPU in einen 
solchen Opcode, wird wiederum eine spezielle TRAP-Routine aufgerufen. Die unteren 12 Bits 
des Befehlsworts kann man dann für eigene Informationen verwenden. 

Bis TOS 1.04 einschließlich werden F-Opcodes intern durch das Betriebssystem für die 
verschiedensten Zwecke benutzt, und daher sollte man von ihnen tunlichst die Finger lassen. 
Die A-Opcodes dienen hingegen zum Aufruf der wichtigsten Grafikroutinen - man kann also 
sagen, daß die Line-A-Routinen auf Maschinenebene die Befehle eines imaginären Grafik- 
Chips emulieren. 

Die Architektur des Betriebssystems spricht allerdings eindeutig gegen die Benutzung der 
Line-A-Routinen. Diese stellen nämlich die untere Ebene des VDI-Bildschirmtreibers im 
ROM dar. Mit ihrer Verwendung verbaut man sich also eine eventuelle Nutzung eines anderen 
(schnelleren) Bildschirmtreibers! 

Auch ist eine Existenz der Line-A-Routinen nur für die ST-Modi (also 320 * 200,640 * 200 
und 640 * 400) garantiert. Schon bei 256-Farbgrafik (spezielle Grafikkarte bzw. TT in der 
“niedrigen” Auflösung) sind die Möglichkeiten der Line-A-Schnittstelle erschöpft (siehe 
“COLBITO” bis “COLB1T3”). 

Wer meint, Line-A-Funktionen im Gegensatz zu VDI-Funktionen im Interrupt aufrufen zu 
können, hat sich übrigens geirrt: auch die Line-A-Funktionen sind nicht re-entrant (einer der 
Gründe: sie sprechen - falls vorhanden - direkt den Blitter an). 

Auch Zeit sparen läßt sich entweder nur wenig oder gar nicht. Ein Beispiel: die Line-A- 
Funktion “Textbit” kann tatsächlich einzelne Zeichen schneller ausgeben als das VDI - kein 
Wunder, macht doch der Bildschirmtreiber im ROM auch nur den gleichen Line-A-Aufruf 
(allerdings per “JSR” statt per Line-A-Ausnahmebehandlung). Normalerweise möchte man 
jedoch mehrere Zeichen (Wörter oder ganze Zeilen) in einem Stück ausgeben. 

Das geht mit“v_gtext()” mit einem VDI-Aufruf (eine Exception-Behandlung), während man 
per Line-A für jedes einzelne Zeichen eine (zeitfressende!) Exception auslösen muß. 
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Es spricht also alles gegen die Verwendung der Line-A-Routinen. Wer will schon Programme 
haben, die bei Hardwareänderungen oder neuen Rechnern dank der Verwendung von Line- 
A-Routinen nicht mehr funktionstüchtig sind? 

Zitat aus den TT030 TOS Release Notes: “The Line-A graphics interface is maintained for 
backward compatibility with existing ST programs only. It should not be used for new pro- 
grams. It will not keep pace with future hardware or Software improvements. The VDI should 
be used.” 

Also: Finger weg von den Line-A-Routinen, wenn es sich nicht gerade um ein systemnahes 
Programm handelt, das sowieso nur auf den drei Standard-Grafikmodi des ST funktionieren 
muß. 


Initialization ($A000) 


Mit diesem Aufruf kann man die Anfangsadressen der Line-A-Variablen, der Line-A- 
Routinen und der Systemzeichensätze erfragen. Initialisiert wird sinnigerweise gar nichts! Zur 
Parameterübergabe an die Line-A-Routinen wird ein Parameterblock folgender Form ver¬ 
wendet (in Klammem jeweils der Offset zur Basisadresse): 


typedef struct 
{ 


WORD 

WORD 

LONG 

LONG 

LONG 

LONG 

LONG 

WORD 

WORD 

WORD 

WORD 

WORD 

WORD 

WORD 

WORD 

LONG 


PLANES; /* Anzahl der Bildschirmebenen (+$00) */ 

WIDTH; /* Bytes pro Bildschirmzeile (+$02) */ 

CONTRL; /* Zeiger auf contrl[] (VDI) (+$04) */ 

INTIN; /* Zeiger auf int_in[] (VDI) (+$08) */ 

PTSIN; /* Zeiger auf pts_in[] (VDI) (+$0C) */ 

INTOUT; /* Zeiger auf int_out[] (VDI) (+$10) */ 

PTSOUT; /* Zeiger auf pts_out[] (VDI) (+$14) */ 

COLBIT0; /* Farbwert für Plane 0 (+$18) */ 

COLBIT1; /* Farbwert für Plane 1 (+$1A) */ 

COLBIT2; /* Farbwert für Plane 2 (+$1C) */ 

COLBIT3; /* Farbwert für Plane 3 (+$1E) */ 

LSTLIN; /* letzten Pixel einer Linie zeichnen (1) oder 
nicht zeichnen (0) +$20) */ 

LNMASK; /* Muster für Linien (+$22) */ 

WMODE; /* VDI-Schreibmodus (+$24) */ 

XI,Y1,X2,Y2; 

/* Koordinatenangaben (+$26) */ 

PATPTR; /* Zeiger auf Füllmuster (+$2E) */ 
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WORD PATMSK; /* dazugehörige Maske (+$32) */ 

WORD MFILL; /* Füllmuster monochr./farbig (+$34)*/ 

WORD CLIP; /* Clipping aus/an (+$36) */ 

WORD XMINCL,YMINCL; 

/* linke obere Ecke des Clip-rect. (+$38) */ 
WORD XMAXCL,YMAXCL; 

/* rechte untere Ecke des Clip-rect. (+$3C) */ 
WORD XDDA; /* vor Textausgaben auf 0x8000 setzen (+$40) */ 
WORD DDAINC; /* Vergrößerungsfaktor - bei Vergrößerung: 

256*(Wunschgröße-Aktuelle)/Aktuelle; bei 
Verkleinerung: 56* (Wunschgröße)/Aktuelle 
(+$42) */ 

WORD SCALDIR; /* Vergrößerungsrichtung (0: verkleinern, 

1: vergrößern (+$44) */ 

WORD MONO; /* Proportionalschrift ja/nein (+$46) */ 

WORD SOURCEX,SOURCEY; 

/* X,Y-Koordinate im Zeichensatz (+$48) */ 

WORD DESTX,DESTY; 

/* Koordinate des Zeichens auf dem Bildschirm 
(+$4C) */ 

WORD DELX,DELY; 

/* Breite und Höhe des Zeichens (+$50) */ 
FONT_HDR *FRÄSE; 

/* Zeiger auf ZeichensatzImage (+$54) */ 

WORD FWIDTH; /* Breite des Zeichensatzimage (+$58) */ 

WORD STYLE; /* Schreibstil (+$5A) 

Bit 0: Fettschrift 

Bit 1: Helle Schrift 

Bit 2: Kursivschrift 

Bit 3: Unterstrichene Schrift 

Bit 4: Umrißschrift */ 

WORD LITEMASK; /* Maske für das Schattieren (light) (+$5C) */ 
WORD SKEWMÄSK; /* Maske für Italics (+$5E) */ 

WORD WEIGHT; /* zusätzliche Breite bei Bold (+$60) */ 

WORD ROFF; /* Kursiv-Offset rechts (+$62) */ 

WORD LOFF; /* Kursiv-Offset links (+$64) */ 

WORD SCALE; /* Vergrößerung ja/nein (+$66) */ 

WORD CHUP; /* Rotationswinkel * 10 (+$68) */ 

WORD TEXTFG; /* Textfarbe (+$6A) */ 

LONG SCRTCHP; /* Zeiger auf temp. Buffer für Texteffekte 
(+$6C) */ 
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WORD SCRPT2; /* Offset für denselben (+$70) */ 

WORD TEXTBG; /* Texthintergrundfarbe (+$72) */ 

WORD COPYTRAN; /* Flag für "COPY RASTER FORM" (0: "opaque", 

1: "transparent") (+$74) */ 

LONG SEEDABORT; 

/* Pointer auf Routine, die nach jeder 
Bildzeile eines "SEEDFILL" aufgerufen wird (+$76) */ 

} LINEA; 

In den Registern DO und A0 erhält man einen Zeiger auf diesen Parameterblock. In der 
Literatur werden häufig auch noch “negative” Offsets zur Line-A-Basisadresse aufgeführt. 
Bei diesen Registern handelt es sich um die lokalen Variablen des Bildschirmtreibers. 

Der Lese-Zugriff ist durch das Dokument “S.A.L.A.D.” offiziell durch Atari freigegeben 
(dabei waren allerdings die Offsets für die Variablen bis einschließlich “MASKJFORM” 
falsch angegeben!) - aber eben ausschließlich für die drei Standard-Grafikmodi des Atari ST. 

Es sei also noch einmal darauf hingewiesen, daß man solche Eigenschaften des ROM- 
Bildschirmtreibers nur dann auszunutzen sollte, wenn das Programm auch sonst ausschließ¬ 
lich über Line-A ausgibt. Auf keinen Fall anstelle der jeweiligen Auskunftsfunktionen des 
VDI benutzen!!! 


typedef struct 
{ 


LONG RESERVED6; /* (-$38E) */ 

FONT HDR *CUR FONT; 


/* Zeiger auf den Header des aktuellen 
Zeichensatzes (-$38A) */ 

WORD RESERVED5[23]; /* (-$386) */ 

WORD M_POS_HX; /* X-Koordinate des Maus~"Hot spot" 

(-$358) */ 


WORD M_POS_HY; 

WORD M_PLÄNES; 

WORD M__CDB_BG; 

WORD M_CDB_FG; 

WORD MASK_FORM[32]; 

WORD INQ TAB[45j; 


/* Y-Koordinate des Maus~"Hot spot" 

(-$356) */ 

/* Maus wird im Replace-Modus (1) oder im 
XOR-Modus (~1) gezeichnet (-$354) */ 

/* Maus-Hintergrundfarbe (-$352) */ 

/* Maus-Vordergrundfarbe (-$350) */ 

/* jeweils abwechselnd für Vordergrund und 
Maske 16 Words (-$34E) */ 

/* Informationen, die bei ”vq_extnd()" 
zurückgeliefert werden (-$30E) */ 
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WORD DEV_TAB[45]; /* Informationen, die man bei "v_opnwk()" 

erhält (-$2B4) */ 

WORD GCÜRX; /* Aktuelle X-Position der Maus <-$25A) */ 

WORD GCÜRY; /* Aktuelle Y-Position der Maus (-$258) */ 

WORD M_HID_CT; /* Anzahl der erfolgten "Hide Mouse 1 ’- 

Aufrufe (-$256) */ 

WORD MOUSE_BT; /* Aktueller Status der Mausknöpfe (-$254) */ 
WORD REQ_COL['48]; /* Interne Daten für "vq_color()" (-$252) */ 
WORD SIZ_TAB[15]; /* Informationen, die bei "vjopnwkO" 

zurückgeliefert werden (~$1F2) */ 

WORD RESERVED4[2]; 

LONG CURJWORK; /* Zeiger auf Attributdaten der aktuellen 

virtuellen Workstation (~$1D0) */ 

FONT_HDR *DEF_FONT; 

/* Zeiger auf den Standardsystemzeichen¬ 
satz (-$1CC) */ 

LONG FONTJRING[4]; /* Drei Pointer auf Zeichensatzlisten 

(verkettete FONT_HDR-Strukturen. Das 
letzte Element enthält eine 0 als 
Endezeichen (-$1C8) */ 

WORD FONT_COUNT; /* Anzahl der Zeichensätze in der 

"FONT_RING"-Liste (-$1B8) */ 

WORD RESERVED3[45]; 

CHAR CUR_MS_STAT; /* Mausstatus: 

Bit 0: linker Knopf 

Bit 1: rechter Knopf 

Bit 2..4: reserviert 

Bit 5: Bewegungsflag (1: Maus wurde 

bewegt) 

Bit 6: gesetzt: Status des rechten 

Knopfes hat sich 
geändert 

Bit 7: gesetzt: Status des linken 

Knopfes hat sich 
geändert (-$15C) */ 

CHAR RESERVED2; 

WORD V_HID_CNT; /* Anzahl der Hide-Cursor-Aufrufe */ 

WORD CUR_X; /* X-Position der Maus (-$158) */ 

WORD CUR_Y; /* Y-Position der Maus (-$156) */ 

CHAR CUR_FLAG; /* <>0, wenn Mauszeiger beim nächsten 

VBlank neu gezeichnet werden muß (-$154) */ 
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CHAR 

LONG 

WORD 

WORD 

LONG 

WORD 


LONG 

LONG 


LONG 

LONG 

LONG 

LONG 

WORD 

WORD 

WORD 

WORD 

WORD 

WORD 

LONG 

WORD 


WORD 

CHAR 

CHAR 

LONG 


MOUSEJTAG; 

RESERVED1; 
V _SAV_XY[2]; 

SAVE_LEN; 

SAVE_ADDR; 

SAVE STAT; 


SAVE_AREA[64]; 
USER TIM; 


NEXTJFIM; 
USER_BUT; 
USER_CUR; 
USER_MOT; 
V _CEL_ H T; 
V_CEL_MX; / 

V_CEL_MY; / 

V_CEL_WR; 

V_COL__BG; 

V_COL_FG; 

V_ CUR _AD; 

V CUR OF; 


V__CUR_XY [2]; 
V_PERIOD; /* 
V_CUR_CT; 

V FNT AD; 


/* <>0, wenn Maus-Interruptbehandlung 
eingeschaltet ist (-$153) */ 

/* gerettete X- und Y-Koordinate des 
Cursors (~$14E) */ 

/* Anzahl der gebutterten Bildzeilen 
(—$14A) */ 

/* Adresse des ersten gebutterten Bytes im 
Bildspeicher (-$148) */ 

/* Bit 0: Buffer ist gültig (1) oder 
ungültig (0) 

Bit 1: Longs (1) oder Words (0) 
gebuffert (-$144) */ 

/* Buffer für Bild unter Mauszeiger 
($-142) */ 

/* aktueller Timer-Interrupt-Vektor; 

sollte zur Beendigung zu "NEXT_TIM" 
springen (-$42) */ 

/* alter Timer-Interrupt-Vektor (-$3E) */ 
/* Maustastenvektor (—$3A) */ 

/* Mausvektor (-$36) */ 

/* Mausbewegungsvektor (-$32) */ 

/* Zeichenhöhe (-$2E) */ 

* maximale Cursor-Spaltenposition (-$2C) */ 

* maximale Cursor-Zeilenposition (-$2A) */ 
/* Character-Zeilenbreite in Bytes (Höhe * 

Breite einer Pixelzeile) (-$28) */ 

/* Hintergrundfarbe (-$26) */ 

/* Vordergrundfarbe (-$24) */ 

/* Adresse der aktuellen Cursorposition 
auf dem Bildschirm (-$22) */ 

/* Vertikaler Offset vom physikalischen 
Bildschirmanfang (kann mit VDI ESC 101 
verändert werden) (~$1E) */ 

/* X- und Y-Position des Cursors (-$1C) */ 
Blinkgeschwindigkeit des Cursors (-$18) */ 
/* Zähler für Cursorblinken (-$17) */ 

/* Zeiger auf Zeichensatzdaten des 

Systemzeichensatzes (siehe auch VDI ESC 
102). Die Zeichenbreiten müssen jeweils 
8 Bytes betragen! (-$16) */ 
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WORD V_FNT_ND; 

WORD V_FNT_ST; 

WORD V_FNT_WD; 

WORD V_REZ_HZ; 
LONG V_OFF__AD; 

WORD RESERVED; 


WORD V_REZ_VT; 
WORD BYTES_LIN; 
} VDIESC; 


/* ASCII-Wert des letzten Zeichens im 
Zeichensatz (-$12) */ 

/* ASCII-Wert des ersten Zeichens im 
Zeichensatz (-$10) */ 

/* Breite der Fontdaten (des Fontimage) in 
Bytes (-$E) */ 

/* Bildschirmbreite in Pixel (-$0C) */ 

/* Zeiger auf Zeichensatz-Offset-Tabelle 
(siehe VDI ESC 102) (-$0A) */ 

/* TOS 1.00: Cursorflag (-$06) 

Bit 0: Blinken aus/ein 

Bit 1: momentaner Blinkstatus: 

normal/invertiert 
Bit 2: Cursor unsichtbar/sichtbar 
Bit 3: Wrapping am Zeilenende ein/aus 
Bit 4: Inverse Darstellung nein/ja 
Bit 5: Cursorposition gespeichert 
nein/ja 

Hat sich seither geändert!!! */ 

/* Bildschirmhöhe in Pixel (-$04) */ 

/* Bytes pro Pixelzeile (-$02) */ 


In Al erhält man einen Zeiger auf eine Tabelle mit Zeigern auf die Systemzeichensätze, 
Zusätzlich enthält A2 einen Zeiger auf eine Tabelle mit den Anfangsadressen der Line-A- 
Routinen. 


Put pixel ($A001) 


Setzt einen Punkt an den angegebenen Koordinaten. Die Parameter müssen in den entspre¬ 
chenden Eingabefeldem des VDI gesetzt werden. Man beachte also die Variablen “INTIN” 


und “PTSIN”. 


Eingabewerte: 

intinfO]: Farbe 

ptsin[0]: X-Koordinate 

ptsin[l]: Y-Koordinate 
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Get pixel ($A002) 

Fragt die Farbe eines beliebigen Punktes auf dem Bildschirm ab. 

Eingabewerte: 

ptsin[0]: X-Koordinate 

ptsin[ 1 ]: Y-Koordinate 

Ausgabewerte: 

DO: Farbe des gegebenen Punkts 


Arbitrary Line ($A003) 

Zeichnet eine Linie zwischen zwei Punkten. Die Linie wird dabei immer von links nach rechts 
gezogen. Für horizontale Linien steht die schnellere Funktion “Horizontal Line” ($A004) zur 
Verfügung, die auch von dieser Funktion genutzt wird. 


Eingabewerte: 


XI: 

Yl: 

X2: 

Y2: 

COLBITO 

COLBIT1 

COLBIT2 

COLBIT3 

LNMASK 

WMODE: 


LSTLIN: 


X-Koordinate des ersten Punkts 
Y-Koordinate des ersten Punkts 
X-Koordinate des zweiten Punkts 
Y-Koordinate des zweiten Punkts 
Bitwert für die erste Farbplane 

Bitwert für die zweite Farbplane (nur bei Low- oder Medium-Res.) 
Bitwert für die dritte Farbplane (nur bei Low-Resolution) 

Bitwert für die vierte Farbplane (nur bei Low-Resolution) 
Bitmuster (Punktmuster) für die Linie 
Schreibmodus: 

0: Replace 

1: Transparent (OR) 

2: Inverse (XOR) 

3: Inverse Transparent (XOR mit not(LN_MASK)) 

Letzen Pixel der Linie zeichnen? (0: nein, 1: ja) 


Ausgabewerte: 

LNMASK: durch den Algorithmus geshiftet 
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Horizontal line ($A0Ö4) 


Zeichnet eine horizontale Linie. Da diese Funktion intern auch für Flächenfüllroutinen benutzt 
wird, ergeben sich interessante weitere Funktionen. 

So kann man statt eines Linienmusters auch mehrere Muster angeben, die dann alternierend 
in aufeinanderfolgenden Zeilen benutzt werden. So kann man sehr leicht mit “Mustern” 
zeichnen. 


Eingabewerte: 


XI: 

Yl: 

X2: 

COLBITO 

COLBIT1 

COLBIT2 

COLBIT3 

WMODE: 


PATPTR: 

PATMSK: 

MFILL: 


X-Koordinate des ersten Punkts 
Y-Koordinate der Linie 
X-Koordinate des zweiten Punkts 
Bitwert für die erste Farbplane 

Bitwert für die zweite Farbplane (nur bei Low- oder Medium-Res.) 
Bitwert für die dritte Farbplane (nur bei Low-Resolution) 

Bitwert für die vierte Farbplane (nur bei Low-Resolution) 
Schreibmodus: 

0: Replace 

1: Transparent (OR) 

2: Invert (XOR) 

3: Inverse Transparent (XOR mit not(Eingabe)) 

Zeiger auf ein Feld von Linienmustem (je 16 Bit) 

Anzahl der verschiedenen Linienmuster 
0: nur in der ersten Farbebene 

>0: alle Farbebenen 


Filled reetangle ($A005) 


Zeichnet ein ausgefülltes Rechteck. 


Eingabewerte: 

XI: X-Koordinate der oberen linken Ecke 

Y1: Y-Koordinate der oberen linken Ecke 

X2: X-Koordinate der unteren rechten ticke 

Y2: Y-Koordinate der unteren rechten Ecke 
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COLBITO: Bitwert für die erste Farbplane 

COLBIT1: Bitwert für die zweite Farbplane (nur bei Low- oder Medium-Res.) 

COLBIT2: Bitwert für die dritte Farbplane (nur bei Low-Resolution) 
COLBIT3: Bitwert für die vierte Farbplane (nur bei Low-Resolution) 
WMODE: Schreibmodus: 



0: 

Replace 


1: 

Transparent (OR) 


2: 

Invert (XOR) 


3: 

Inverse Transparent (XOR mit not(Eingabe)) 

PATPTR: 

Zeiger auf ein Feld von Linienmustem (je 16 Bit) 

PATMSK: 

Anzahl der verschiedenen Linienmuster 

MFDLL: 

0: 

nur in der ersten Farbebene 


>0: 

alle Farbebenen 

CLIP: 

Clipping: 0: aus, 1: an 

XMINCL: 

Oberer Rand des Clip-Rechtecks 

XMAXCL: 

Unterer Rand des Clip-Rechtecks 

YMINCL: 

Linker Rand des Clip-Rechtecks 

YMAXCL: 

Rechter Rand des Clip-Rechtecks 


j Filledpolygon($A006) 


Die Bezeichnung dieser Funktion ist ein wenig irreführend, da lediglich eine Zeile des Poly¬ 
gons gefüllt wird. 

Um das gesamte Polygon zu füllen, muß man also die Funktion mehrfach aufrufen. 

Im ptsin[]"Feld werden die Koordinaten der Eckpunkte angegeben. Als letzter Punkt muß 
natürlich noch mal der Anfangspunkt angegeben werden, da man sonst keine geschlossene 
Figur erhält. 


Eingabewerte: 


ptsinl ]: 

contrl[l]: 

Yl: 

COLBITO 

COLBIT1 

COLBIT2 

COLBIT3 


Enthält die Koordinaten der Eckpunkte des Polygonzugs 
Anzahl der Koordinaten in ptsin[] 

Y-Koordinate der zu zeichnenden Linie 
Bitwert für die erste Farbplane 

Bitwert für die zweite Farbplane (nur bei Low- oder Medium-Res.) 
Bitwert für die dritte Farbplane (nur bei Low-Resolution) 

Bitwert für die vierte Farbplane (nur bei Low-Resolution) 
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WMODE: 


PATPTR: 

PATMSK: 

MFILL: 

CLIP: 

XMINCL: 

XMAXCL: 

YMINCL: 

YMAXCL: 


Schreibmodus: 

0: Replace 

1: Transparent (OR) 

2: Inveit (XOR) 

3: Inverse Transparent (XOR mit not(Eingabe)) 

Zeiger auf ein Feld von Linienmustem (je 16 Bit) 
Anzahl der verschiedenen Linienmuster 
0: nur in der ersten Farbebene 

>0: alle Farbebenen 

Clipping (0: aus, 1: an) 

Oberer Rand des Clip-Rechtecks 
Unterer Rand des Clip-Rechtecks 
Linker Rand des Clip-Rechtecks 
Rechter Rand des Clip-Rechtecks 


Ausgabewerte: 

XI und X2 werden verändert; A0 wird zerstört 


Bitbit (Bit Biock Transfer) ($A007) 


Dies ist die Grundfunktion für “Text Block Transfer” ($A008) und “Copy raster form” 
($AOOE). Einziger Eingabewert für diese Funktion ist das Adreßregister A6, das einen Zeiger 
auf eine BITBLT-Struktur enthalten muß: 

typedef struct { 

WORD B__WD; /* Breite des Blocks in Pixeln */ 

WORD B_HT; /* Höhe des Blocks in Pixeln */ 

WORD PLANE_CT; /* Anzahl der Farbplanes; wird durch "Bitbit" 
zerstört */ 

WORD FG_COL; /* Vordergrundfarbe; wird durch "Bitbit" 
zerstört */ 

WORD BG_COL; /* Hintergrundfarbe; wird durch "Bitbit" 
zerstört */ 

LONG OP_TAB; /* Logische Verknüpfungen für alle vier 
Kombinationen von Vordergrund- und 
Hintergrundbits (siehe die 16 möglichen 
Verknüpfungen für Blitter-Operationen) */ 

/* X-Koordinate des Quellrasters */ 


WORD S XMIN; 
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WORD 

LONG 

WORD 

WORD 

WORD 

WORD 

WORD 

LONG 

WORD 

WORD 

WORD 

LONG 

WORD 
WORD 
WORD 
CHÄR 
} BITBLT; 


S__YMIN; /* Y-Koordinate des Quellrasters */ 

SJFORM; /* Anfangsadresse des Quellrasters */ 

S_NXWD; /* Offset zum nächsten Wort in der gleichen 
Plane (HighRez 2, MedRez 4, LowRez 8) */ 
S_NXLN; /* Breite des Quellrasters in Bytes */ 

S_NXPL; /* Offset zur nächsten Plane (beim ST immer 2) */ 
D__XMIN; /* X-Koordinate des Zielrasters */ 

D_YMIN; /* Y-Koordinate des Zielrasters */ 

D_FORM; /* Anfangsadresse des Zielrasters */ 

D_NXWD; /* Offset zum nächsten Wort in der gleichen 
Plane (Zielraster) */ 

DJNXLN; /* Breite des Zielrasters in Bytes */ 

D_NXPL; /* Offset zur nächsten Plane (beim ST immer 2) */ 
P_ADDR; /* Zeiger auf 16-Bit-Masken, mit denen jeweils 
undiert wird. (0 = keine Maske) */ 

P_NXLN; /* Höhe der Maske in Bytes (eine Potenz von 2) */ 
P_NXPL; /* Zeiger auf nächste Plane in der Maske */ 
P_MASK; /* Höhe der Maske in Zeilen */ 

SPACE[24];/* interner Arbeitsbereich für "Bitbit" */ 


Bemerkungen 

Clipping findet nicht statt. Weiterhin wird nicht getestet, ob die angegebenen Ausschnitte 
tatsächlich innerhalb der benutzten Memory-Form liegen. 


TextBIt (Text Block Transfer) ($A008) 


Dies ist eine universelle Routine zur Ausgabe von einzelnen Zeichen auf dem Bildschirm. Zu 
ihren vielfältigen Funktionen zählen die Drehung von Zeichen (in 90-Grad-Schritten), 
verschiedene Textattribute und diverse Schriftgrößen. Bei “TextBIt” ergeht es einem nicht 
anders als bei anderen “Monster-Routinen” des Betriebssystems - je universeller, desto mehr 
Register muß man setzen und desto umständlicher ist die Handhabung. 

Bevor wir uns aber auf die einzelnen Eingabeparameter stürzen, seien noch ein paar Worte 
zum Aufbau eines Zeichensatzes gesagt. 

Von “konventionellen” Rechnern war man an einen sehr einfachen Aufbau von Zeichensätzen 
gewöhnt. Da hatten alle Zeichen die gleiche Breite und Höhe, besondere Schriftattribute 
wurden - wenn überhaupt verfügbar- von der Hardware erzeugt, und verschiedene, gleich- 
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zeitig verwendbare Zeichensätze waren überhaupt kein Thema. Ganz anders ist es unter TOS. 
Dadurch, daß alle Bildschirmausgaben im Grafikmodus erfolgen, kann das Betriebssystem 
verschiedene Textattribute (wie Fettschrift oder kursiv) direkt unterstützen. Zusätzlich wol¬ 
len auch noch Dinge wie Proportionalschrift verwaltet sein. Womit wir schon beim Problem 
angelangt sind - wie legt man möglichst speicherplatzsparend einen Zeichensatz im Speicher 
ab? Atari hat folgende Lösung gewählt: der Zeichensatz wird einfach als großes “Bild” 
betrachtet, dessen Höhe die Zeichenhöhe und dessen Breite die Sum-me aller Zeichenbreiten 
ist. 

Alle Zeichen stehen in diesem “Fontimage” direkt nebeneinander. Auf diese Weise geht zwar 
kein einziges Bit verloren, dafür muß aber die Position eines jeden Zeichens erst mittels einer 
Offset-Tabelle berechnet werden. Für GEM-Zeichensätze gibt es ein Standard-Dateiformat, 
wie es zum Beispiel auch von GDOS gelesen wird (siehe dazu Einführung ins VDI). Damit 
ist die Zeichenausgabe auf das Kopieren eines Ausschnitts aus einem imaginären Bildschirm 
(dem Zeichensatz) auf den tatsächlichen Bildschirm reduziert - und dafür gibt es ja andere 
Routinen. 


Eingabewerte: 

WMODE: Schreibmodus: 

0: 

Replace 

1: 

Transparent (OR) 

2: 

Invert (XOR) 

3: 

Inverse Transparent (XOR mit not(Eingabe)) 

4-19: Bitbit-Modi 0-15 

CLIP: 

Clipping aus (0) oder an (1) 

XMINCL: 

Oberer Rand des Clip-Rechtecks 

XMAXCL: 

Unterer Rand des Clip-Rechtecks 

YMINCL: 

Linker Rand des Clip-Rechtecks 

YMAXCL: 

Rechter Rand des Clip-Rechtecks 

XDDA: 

Vor jedem Aufruf auf $8000 setzen 

DDAINC: 

Vergrößerungsfaktor 

SCALDIR: 

Vergrößerungsrichtung 

MONO: 

0: Zeichen können verschiedene Breiten haben (wg. Texteffekten 

SOURCEX: 

oder Proportionalschrift) 

1: Alle Zeichen haben die gleiche Breite 

X-Position des Zeichens im Fontimage (Berechnung: zunächst vom 

SOURCEY: 

ASCII-Wert “first_ade” abziehen und diesen Wert dann als Index in die 
Offset-Tabelle “offjable” verwenden) 

Y-Position des Zeichens im Fontimage. Gewöhnlich 0. 

DESTX: 

X-Zielkoordinate 
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DESTY: 

Y-Zielkoordinate 

DELX: 

Breite des Zeichens (dazu subtrahiert man die X-Position von der X- 
Position des folgenden Zeichens) 

DELY: 

Höhe des Zeichens (üblicherweise “form_height”) 

FBASE: 

Zeiger auf Zeichensatzdaten (“dat_table”) 

FWIDTH: 

Breite des Zeichensatzimage (“form_width”) 

STYLE: 

Texteffekte: Bit 0: Fettschrift 

Bit 1: Helle Schrift 

Bit 2: Kursivschrift 

Bit 3: Unterstrichen (wird ignoriert) 

Bit 4: Umrissene Schrift (“outline”) 

LITEMASK: 

Maske für helle Schrift (“lighten”) 

SKEWMASK: 

Maske für Kursivschrift (“skew”) 

WEIGHT: 

Zusätzliche Breite für Fettschrift (“thicken”) 

ROFF; 

Rechter Offset des Zeichens bei Kursivschrift (“right_offset”) 

LOFF: 

Linker Offset des Zeichens bei Kursivschrift (“left_offset”) 

SCALE: 

Scaling aus (0) oder ein (1) 

CHUP: 

Schriftrichtung in 1/10 Grad (also 0, 900, 1800 oder 2700) 

TEXTFG: 

Textfarbe 

SCRTCHP: 

Zeiger auf einen Buffer, der zur Erzeugung der Texteffekte benötigt 
wird (2 * Maximalgröße eines Zeichens) 

SCRPT2: 

Offset zur Mitte des Buffers (=1/2 der Länge des Buffers) 

TEXTBG: 

Texthintergrundfarbe 

Show raouse ($A009) 


Diese Routine istdiedirekte Entsprechung der“Show Cursor”-Funktion des VDI(“v„show_c()”) 
und dient zum Einschalten des Mauscursors. Intern wird mitgezählt, wie oft die Maus vorher 
abgeschaltet worden ist, so daß man gegebenenfalls die Aufrufe verschachteln kann. Die Maus 
wird nur dann angezeigt, wenn dieser interne Zähler wieder auf 0 steht. Diesen Mechanismus 
kann man allerdings mittels des Parameters in intinfO] ausschalten. 


Eingabeparameter: 

intin[0]: 0: Maus auf jeden Fall wieder einschalten 

>0: normale Arbeitsweise 

Bemerkungen 

Die Lirie-A-Zeiger auf die VDI-Eingabefelder müssen natürlich auch korrekt gesetzt sein! 
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Hide mouse ($A00A) 


Pendant zur vorhergehenden Funktion (schaltet den Mauscursor aus). 


Transform mouse ($AO0B) 


Mit dieser Funktion kann man das Erscheinungsbild der Maus ändern. Im intin[)-Feld wird 
eine MFORM-Struktur erwartet. 


Die einfachste Art der Parameterübergabe ist, sich zunächst den alten Zeiger auf das intin[]- 
Feld zu merken (INTIN) und mit einem Zeiger auf die MFORM-Struktur zu überschreiben. 
Nach Ausführung der Funktion stellt man dann den Vektor wieder her. 

Die Mausform-Struktur sieht folgendermaßen aus: 

typedef struct 
{ 

WORD 
WORD 
WORD 
WORD 
WORD 
WORD 
WORD 
) MFORM; 

Der Aktionspunkt ist dabei die Stelle innerhalb des Mauscursors, auf die sich alle Maus-Koor¬ 
dinatenangaben beziehen. Beim einfachen Pfeil liegt der Aktionspunkt beispielsweise in der 
linken oberen Ecke (0,0). 


mf xhot; 

/* 

mf yhot; 

/* 

mf nplanes; 

/* 

mf_fg; 

/* 

mf bg; 

/* 

mf mask[16]; 

/* 

mf data[16]; 

/* 


/* Aktionspunkt X-Koordinate */ 
/* Aktionspunkt Y-Koordinate */ 
auf 1 setzen */ 

Maskenfarbe */ 

Cursorfarbe */ 

Maskendaten (16*16 Punkte) */ 
Cursordaten (16*16 Punkte) */ 


Undraw sprite ($A00C) 


Löscht ein mit “DRAW SPRITE” gezeichnetes Sprite vom Bildschirm und stellt den Hinter¬ 
grund wieder her. Die Funktion erwartet in A2 einen Zeiger auf den Sprite-Save-Block (siehe 
“DRAW SPRITE”). Register A6 wird zerstört. 
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Draw sprite ($A00D) 


Zeichnet ein bis zu 16* 16 Punkte großes Sprite auf dem Bildschirm. Register A6 wird zerstört. 


Eingabewerte: 

DO: X-Koordinate des Aktionspunktes des Sprites auf dem Bildschirm 

Dl: Y-Koordinate 

AO: Zeiger auf SDB-Struktur 

A2: Zeiger auf Sprite-Save-Buffer (Größe in Bytes: 10+64 * Anzahl der Farbebenen). Die 
Adresse dieses Buffers muß auch an “UNDRAW SPRITE” übergeben werden. 


typedef struct 


WORD xhotf 
WORD yhot; 

WORD form; 

WORD bgcol; 
WORD fgcol; 
WORD image[32]; 
} SDB; 


/* X-Koordinate des Aktionspunkts */ 
/* Y-Koordinate des Aktionspunkts */ 
/* 1: VDI-Format, -1: XOR-Format */ 
/* Hintergrundfarbe */ 

/* Vordergrundfarbe */ 

/* Sprite-Image */ 


In den Sprite-Daten wechseln sich jeweils ein Wort für den Vordergrund und ein Wort für den 
Hintergrund ab. Es ergeben sich folgende Verknüpfungen (old sei der bisherige Pixelwert des 
Bildpunkts): 


Vordergr.-Bit 

Hintergr.-Bit 

VDI-Format 

XOR-Format 

0 

0 

new-old 

new=old 

0 

1 

new=bgcol 

new=bgcol 

1 

0 

new^fgcol 

new-fgcol xor old 

1 

1 

new-fgcol 

new=fgcol 


Copy raster form ($A00E) 


Diese Funktion entspricht exakt der VDI-Funktion “COPY RASTER, OPAQUE”, mit der 
Ausnahme, daß das contrl[]-Feld nicht vollständig gesetzt und keine Workstation geöffnet zu 
werden braucht. Man muß lediglich die Elemente im ptsin[]-Feld und contr][7-10] ausfüllen. 
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Seedfill ($AOOF) 


Entspricht exakt der VDI-Funktion, mit folgenden Ausnahmen: 

- Man braucht keine Workstation zu öffnen. 

- Die Clipping-Variablen müssen gesetzt werden. 

- SEEDABORT ist ein Zeiger auf eine Routine, die am Ende jeder Bildschirmzeile einmal 
aufgerufen wird. Liefert sie in DO einen Wert ungleich 0 zurück, wird der Füllvorgang 
abgebrochen. 


Plottertreiber 

Einleitung 

GDOS-Plottertreiber für den Atari gibt es meines Wissens bislang nicht. Ich würde mich 
allerdings gerne eines Besseren belehren lassen! 

Mindestfunktionsumfang 

(Spezifikation nach Atari, “GEM Programmer’s Guide”) 


Opcode 

Funktion 

1 

Open workstation 

2 

Close workstation 

3 

Clear workstation 

4 

Update workstation 

5 

Escape-functions 

1 

Inquire addressable character cells 

6 

Polyline 

7 

Polymarker 

8 

Text 

9 

Filled area 

11 

Generalized Drawing Primitive (GDP) 

1 

Bar 

2 

Are 

3 

Pie 
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Opcode 


Funktion 


4 

5 

6 

7 

8 
9 

10 

12 

15 

17 

18 
20 
21 
22 

23 

24 

25 

35 

36 

37 

38 

39 
102 
104 

107 

108 
116 
117 

130 

131 


Circle 

Ellipse 

Elliptical arc 

Elliptical pie 

Rounded rectangle 

Filled rounded rectangle 

Justified graphics text 

Set character height, absolute mode 

Set polyline linetype 

Set polyline color Index 

Set polymarker type 

Set polymarker color index 

Set text face 

Set graphic text color index 

Set fill interior style 

Set fill style index 

Set fill color index 

Inquire current polyline attributes 

Inquire current polymarker attributes 

Inquire current fill area attributes 

Inquire current graphic text attributes 

Set graphic text alignment 

Extended inquire function 

Set fill perimeter visibility 

Set character cell height, points mode 

Set polyline end styles 

Inquire text extent 

Inquire character cell width 

Inquire face name and index 

Inquire current face Information 


Druckertreiber 

Besonderheiten 

GDOS-Druckertreiber gibt es mittlerweise in allen Formen und Farben - angefangen beim 
Epson-kompatiblen bis zum Atari-Laserdrucker. Selbst Treiber für HP-Laserdrucker und 
Postscript-Ausgabegeräte wurden schon gesichtet. 
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Eingetragene Entwickler können bei Atari das sogenannte “Treiber-Entwicklungs-Paket” 
bekommen. Es besteht aus einer kompletten Bibliothek, die nur noch um einige wenige 
druckerspezifische Funktionen erweitert werden muß, um einenTreiberfüreinenmonochromen, 
grafikfähigen Drucker zu erzeugen. Bei der Arbeit mit VDI-Druckertreibem beachte man, daß 
nicht alle Treiber funktional völlig identisch sind. Bei Verwendung des Lasertreibers gibt es 
nicht nur zusätzliche Funktionen, sondern einige bestehende wurden auch teilweise erweitert. 
Auf Unterschiede wird bei den einzelnen Funktionen jeweils getrennt hingewiesen. 

Schließlich sei noch einmal auf die erst ab GEM 2.0 dokumentierten Escape-Funktionen 
“v_q_scan()” und “v_alpha _text()” hingewiesen, die eine sehr einfache Möglichkeit zur stan¬ 
dardisierten Textausgabe liefern. 

Mindestfunktionsumfang 

(Spezifikation nach Atari, “GEM Programmer’s Guide”) 


Opcode 

Funktion 

1 

Open workstation 

2 

Close workstation 

3 

Clear workstation 

4 

Update workstation 

5 

Escape-functions 

1 

Inquire addressable character cells 

20 

Form advance 

21 

Output window 

22 

Clear display list 

23 

Output bit image file 

6 

Polyline 

7 

Polymarker 

8 

Text 

9 

Filled area 

11 

Generalized Drawing Primitive (GDP) 

1 

Bar 

2 

Are 

3 

Pie 

4 

Circle 

5 

Ellipse 

6 

Elliptical arc 

7 

Elliptical pie 

8 

Rounded rectangle 
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Opcode 

Funktion 

9 

Filled rounded rectangle 

10 

Justified graphics text 

12 

Set character height, absolute mode 

15 

Set polyline linetype 

17 

Set polyline color index 

18 

Set polymarker type 

20 

Set polymarker color index 

21 

Set text face 

22 

Set graphic text color index 

23 

Set fill interior style 

24 

Set fill style index 

25 

Set fill color index 

26 

Inquire color representation 

32 

Set writing mode 

35 

Inquire current polyline attributes 

36 

Inquire current polymarker attributes 

37 

Inquire current fill area attributes 

38 

Inquire current graphic text attributes 

39 

Set graphic text alignment 

102 

Extended inquire function 

104 

Set fill perimeter visibility 

106 

Set graphic text special effects 

107 

Set character cell height, points mode 

108 

Set polyline end styles 

112 

Set user-defined fill pattem 

116 

Inquire text extent 

117 

Inquire character cell width 

129 

Set clipping rectangle 

130 

Inquire face name and index 

131 

Inquire current face Information 


Metafile-Treiber 

Einleitung 

Der Metafile-Treiber ermöglicht es, VDI-Befehle in geräteunabhängiger Form in eine Datei 
zu schreiben. Der so erzeugte Metafile enthält eine “Aufzeichnung” aller getätigten VDI- 
Aufrufe inklusive aller Parameter. 
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Format von Metafiles 

Wer Metafiles lesen können will, muß das Format des Metafile-Headers kennen: 


typedef struct 

{ 

WORD mf_header; 
WORD mf_hlength; 
WORD mf Version; 


WORD mf_ndcrcfl; 
WORD mf_extents[4]; 


WORD mf_pagesz[2]; 


WORD mf coords[4]; 


WORD mf_imgflag; 


WORD mf_resvd[9]; 

} METAHDR; 


/* -1 (Metafile-Kennung) */ 

/* Länge des Headers in Integers (24) */ 
/* bei der aktuellen Version 101 
(Version 1.01), Formel: 
100*Hauptnummer+Unternummer */ 

/* NDC/RC-Flag (0 oder 2) */ 

/* optional - maximale Ausmaße der 
Grafik - können mit 
"v_meta_extents()" gesetzt werden 
(sonst mit 0 gefüllt) */ 

/* optional - Seitengröße in 1/10 mm - 
kann mit "vm_pagesize()" gesetzt 
werden (sonst mit Nullen gefüllt) */ 
/* optional - Koordinatensystem - kann 
mit "vm_coords()" gesetzt werden 
(sonst mit Nullen gefüllt) */ 

/* falls Bit 0=1, so enthält die Datei 
Bitimages, sonst nicht. Die anderen 
Bits sind immer 0. */ 

/* zur Zeit unbenutzt */ 


Beim Lesen der Metafiles wird keine feste Länge benutzt. Vielmehr liest eine Applikation erst 
die ersten beiden Wörter und damit die Länge des Headers. Anschließend wird der Rest des 
Headers gelesen. Es folgen dann “beliebig” viele Einträge folgender Form : 


Wort 

Inhalt 

Belegung 

0 

contrl[0] 

VDI-Befehlsnummer 

1 

contrl[l] 

Anzahl der Werte im ptsin[]-Feld 

2 

contrl[3] 

Anzahl der Werte im intin[]-Feld 

3 

contrl[5] 

Unterfunktionsnummer 

ab 4 

ptsin[] 

Alle belegten Felder des ptsin[]-Feldes 

es folgt 

intin[] 

Alle belegten Felder des intin[]-Feldes 
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Speziell behandelt werden die Funktionen “v_opnwk()’\ die die Datei öffnet und alle 
Standard-Attribute als Aufrufe von Attributfunktionen in die Datei schreibt, “v._dswk()’\ die 
als Endekennung eine “-1” in die Datei schreibt, und einige Escapefunktionen, die Werte in 
den Header der Metadatei eintragen (oder sie umbenennen). 

Fehler bei der Ausgabe in Dateien werden auf ausgesprochen humorvolle Weise beanstandet 
- in “ptsout[0]” und “ptsout[lj” werden die Ziffern “987” bzw. “654” geschrieben (nicht 
offiziell dokumentiert!). Was Digital Research sich dabei gedacht hat, wird wohl für immer 
ein Rätsel bleiben. Unbedingt zu beachten ist ferner, daß alle Wörter im Intel-Format (also 
High- und Low-Byte vertauscht) abgelegt werden! 

Erweiterte Opcodes 

Der Hauptzweck von Metafiles ist der standardisierte Datenaustausch zwischen GEM- 
Applikationen. Die PC-Version von GEM wird von deutschen Softwarehaus CCP gepflegt, 
das auch das bekannte Anwendungsprogramm “GEM Artline” entwickelt hat. 

Viele Atari-Programme bemühen sich, GEM/3-kompatible Metafiles lesen und schreiben zu 
können. Die Unterschiede zum oben beschriebenen Format ergeben sich ausschließlich durch 
das mögliche Auftreten von Opcodes neuer VDI-Funktionen (wie etwa Bezierkurven oder 
Grauraster). GEM/4 (in Artline 2) kennt weitere Funktionen wie etwa zum Setzen von Farb- 
verläufen. 

Daher ist es leider nicht möglich, an dieser Stelle exakt und vollständig zu beschreiben, was 
alles in einem Metafile stehen kann - das hängt ausschließlich davon ab, welches Programm 
die Datei erzeugt und welches sie einiesen können soll. Im Zweifelsfall muß man bei Digital 
Research die aktuellen Entwicklerunterlagen zu PC-GEM erwerben. 

Vielleicht ringt sich Atari eines Tages selbst zu einer überarbeiteten Spezifikation durch. 

Mindestfunktionsumfang 

(Spezifikation nach Atari, “GEM Programmer’s Guide”) 


Opcode 

Funktion 

1 

Open workstation 

2 

Close workstation 

3 

Clear workstation 

4 

Update workstation 

5 

Escape-functions 
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Opcode 

Funktion 

1 

Inquire addressable character cells 

2 

Exit alpha mode 

3 

Enter alpha mode 

20 

Form advance 

21 

Output window 

22 

Clear display list 

23 

Output bit Image fde 

98 

Update metafile extents 

99 

Write metafile item 

100 

Change GEM VDI filename 

6 

Polyline 

7 

Polymarker 

8 

Text 

9 

Filled area 

11 

Generalized Drawing Primitive (GDP) 

1 

Bar 

2 

Are 

3 

Pie 

4 

Circle 

5 

Ellipse 

6 

Elliptical arc 

7 

Elliptical pie 

8 

Rounded rectangle 

9 

Filled rounded rectangle 

10 

Justified graphics text 

12 

Set character height, absolute mode 

13 

Set character baseline vector 

14 

Set color representation 

15 

Set polyline linetype 

16 

Set polyline line width 

17 

Set polyline color index 

18 

Set polymarker type 

19 

Set polymarker height 

20 

Set polymarker color index 

21 

Set text face 

22 

Set graphic text color index 

23 

Set fill interior style 

24 

Set fill style index 

25 

Set fill color index 
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Opcode 

i 

Funktion 

26 

Inquire color representation 

32 

Set writing mode 

35 

Inquire current polyline attributes 

36 

Inquire current polymarker attributes 

37 

Inquire current fill area attributes 

38 

Inquire current graphic text attributes 

39 

Set graphic text alignment 

102 

Extended inquire function 

103 

Contour fill 

104 

Set fill perimeter visibility 

106 

Set graphic text special effects 

107 

Set character cell height, points mode 

108 

Set polyline end styles 

112 

Set user-defined fill pattem 

113 

Set user-defined line style pattem 

114 

Fill rectangle 

117 

Inquire character cell width 

129 

Set clipping rectangle 

131 

Inquire current face information 


Kameratreiber 

Einleitung 

Treiber für die “Polaroid Palette” sind nicht erhältlich und werden wohl auch nicht mehr 
implementiert werden (aber wer weiß...). In der Dokumentation zu GEM 2.0 hat Digital 
Research sämtliche Funktionen geändert-da es sowieso bislang keine Treiber gibt, haben wir 
hier alle Änderungen vollständig übernommen! 

Mindestfunktionsumfang 

(Spezifikation nach Digital Research zu GEM 2.0) 


Opcode 

Funktion 

1 

Open Workstation 

2 

Close workstation 

3 

Clear workstation 
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Opcode 

Funktion 

4 

Update Workstation 

5 

Escape-functions 

1 

Inquire addressable character cells 

23 

Output bit image file 

91 

Select camera film type and exposure time 

92 

Inquire camera film name 

6 

Polyline 

ii 

Generalized Drawing Primitive (GDP) 

i 

Bar 

2 

Are 

3 

Pie 

4 

Circle 

5 

Ellipse 

6 

Elliptical arc 

7 

Elliptical pie 

8 

Rounded rectangle 

9 

Filled rounded rectangle 

10 

Justified graphics text 

12 

Set character height, absolute mode 

13 

Set character baseline vector 

14 

Set color representation 

15 

Set polyline linetype 

16 

Set polyline line width 

17 

Set polyline color index 

18 

Set polymarker type 

19 

Set polymarker height 

20 

Set polymarker color index 

21 

Set text face 

22 

Set graphic text color index 

23 

Set fill interior style 

24 

Set fill style index 

25 

Set fill color index 

26 

Inquire color representation 

32 

Set writing mode 

35 

Inquire current polyline attributes 

36 

Inquire current polymarker attributes 

37 

Inquire current fill area attributes 

38 

Inquire current graphic text attributes 

39 

Set graphic text alignment 
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Opcode 

Funktion 

102 

Extended inquire function 

104 

Set fill perimeter visibility 

106 

Set graphic text special effects 

107 

Set character cell height, points mode 

108 

Set polyline end styles 

112 

Set user-defined fill pattem 

113 

Set user-defined line style pattem 

116 

Inquire text extent 

117 

Inquire character cell width 

119 

Load fonts 

120 

Unload fonts 

129 

Set clipping rectangle 

130 

Inquire font name and index 

131 

Inquire current face Information 
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VDI-Referenz 

Kontrollfunktionen 


OPEN WORKSTATION (VDI1) 


“OPEN WORKSTATION” initialisiert einen Grafik-Gerätetreiber für ein bestimmtes Ein-/ 
Ausgabegerät. Ein Eingabefeld teilt die dazu notwendigen Parameter mit, Informationen über 
das Gerät erhält man in einem speziellen Ausgabefeld. Gerätetreiber müssen in der 
ASSIGN.SYS-Datei, die beim Booten von GDOS gelesen wird, angemeldet sein (siehe 
Erläuterungen zum Aufbau der ASSIGN.SYS-Datei). 

Sollte es sich um einen Bildschirmtreiber handeln, so wird der Grafik-Modus gestartet. Im 
Normalfall sind es die AES, die die Bildschirm-Workstation für sich öffnen. Anwendungs¬ 
programme müssen daher virtuelle Workstations öffnen. Nur wenn die AES noch nicht aktiv 
sind (während der Abarbeitung des AUTO-Ordners), ist es möglich, Bildschirm-Workstations 
zu öffnen. Wird OPEN WORKSTATION dazu benutzt, einen Metafile zu öffnen, so schreibt 
diese Funktion den Metafileheader und initialisiert den Dateipuffer. Wenn die Funktion 
erfolgreich war, wird in contrl[6] eine Gerätekennung übergeben, sonst ist contrl[6] gleich 0 
(Vorsicht: Die allermeisten GDOS-Versionen können nicht beliebig viele Workstations öff¬ 
nen!). 

Deklaration in C: 

void v_opnwk (WORD *work_in, WORD *handle, WORD *work_out) 

{ 

iioff = work_in; 
iooff = work_out; 
pooff = work__out+45; 
contrl[0] = 1; 
contrl[l] = 0; 
contrl[3] = 11; 
vdi (); 

*handle = contrl[6]; 
iioff = intin; 
iooff ~ intout; 
pooff » ptsout; 
pioff = ptsin; 


) 
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GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrlfO] 

1 

Opcode für V_OPNWK 

eontrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

6 

# Einträge in ptsout 

contrl+6 

contrl[3] 

11 

# Einträge in intin 

contrl+8 

contrl[4] 

45 

# Einträge in intout 

contrl+12 

contrl[6] 

handle Gerätekennung 

intin 

intin[0.. 10] 

work_in[0..10] 

intout 

intout[0..44] 

work_out[0..44] 

ptsout 

ptsout[0..11] 

work_out[45..56] 


Parameter: 

work_in[0]: 


work_in[l]: 

work_in[2]: 

work_in[3]: 
work_in[4]: 
work_in[5]: 
work _in[6]: 
work_in[7]: 
workJn[8]: 


work_in[9]: 


Gerätidentifikationsnummer, bestimmt den zu ladenden Gerätetreiber (siehe 
auch ASSIGN.SYS-Datei): 

1: Bildschirmtreiber (aktuelle Auflösung) 

2+Getrez(): Bildschirmtreiber (das VDI schaltet selbsttätig in die entspre¬ 
chende Auflösung; nur für die Standard-Auflösungen von ST 
und TT definiert), 
ab 11: Plottertreiber 
ab 21; Druckertreiber 
ab 31: Metafile-Treiber 
ab 41: Kamera 
ab 51: Grafiktablett 
Linientyp 

Linienfarbe (wird auf 1 gesetzt, falls die Werte bei work_in[2], work_in[4], 
work_in[6] bzw. work„in[9] falsch gesetzt werden) 

Markertyp 

Markeifarbe 

Zeichensatznummer 

Textfarbe 

Fülltyp 

Füllmuster-Index (Bemerkung; bei diesem Parameter existiert ein Fehler im 
VDI. Er wird um den Wert 1 zu hoch übernommen, d. h. bei Angabe von n wird 
Füllmuster n + 1 gewählt.) 

Füllmuster-Farbe 
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work_in[10]: 


work_out[0]: 

work_out[l]: 

work_out[2]: 


work_out[3]: 


work_out[4]: 

work_out[5j: 

work_out[6]: 

work_out[7]: 

work_out[8]: 

work_out[9]: 

work_out[10j: 

work_out[ 11]: 

work_out[12]: 

work_out[I3]: 

work_out[14]: 

work_out[15] bis 

work_out[24]: 


Koordinaten-Flag 

0: NDC-Koordinaten (nur mit GDOS) 

1: reserviert 

2: RC-Koordinaten 

Vorsicht: Je nach verwendetem GDOS wird bei einem ungültigen Wert 
entweder NDC oder RC gewählt! 

Maximale horizontale Pixelposition 
(beispielsweise im Grafikmodus “ST-Hoch”: 639) 

Maximale vertikale Pixelposition 
(beispielsweise im Grafikmodus “ST-Hoch”: 399) 
Gerätekoordinaten-Flag 

0: Bild kann genau skaliert werden (wie auf dem Bildschirm) 

1: Bild kann nicht genau skaliert werden (wie auf Film-Recordern) 

Breite eines Pixels (oder Plotterschrittweite) in Mikrometern (=mm/ 
1000). FürBildschirme sind work_out[3] und work_out[4] prinzipbedingt 
nicht exakt (das Betriebssystem kennt schließlich nicht die benutzte 
Bilddiagonale). Immerhin kann man den Quotienten aus beiden Werten 
sinnvoll auswerten! 

Höhe eines Pixels (oder Plotterschrittweite) in Mikrometern 
(=mm/1000) 

Anzahl der Schriftzeichenhöhen (0: beliebig veränderbar) 

Anzahl der Linientypen 

Anzahl der Linienbreiten (0: beliebig veränderbar) 

Anzahl der Markertypen 

Anzahl der Markergrößen (0: beliebig veränderbar) 

Anzahl der verfügbaren Zeichensätze (kann mehr als einer sein!) 

Anzahl der Muster 

Anzahl der Schraffuren 

Anzahl der vordefinierten Farben 

Anzahl der Grafikgrundfunktionen (GDP) 

Liste der unterstützten Grafikgrundfunktionen (GDP). 

Das Ende ist durch -1 gekennzeichnet. 

GEM VDI unterstützt die folgenden 10 Grundfunktionen: 

1: Balken 

2: Bogen 

3: Kreissegment (-ausschnitt) 

4: Kreis 

5; Ellipse 

6: elliptische Bogen 

7: Ellipsensegment (-ausschnitt) 
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work_out[25] bis 
work_out[34j: 


work_out[35] 

work_out[36] 

work_out[37] 

work_out[38] 

work_out[39] 


work_out[40]: 


work_out[41]: 


work_out[42]: 


work_out[43]: 


work_out[44]: 

0 

1 

2 

3 

4 

work_out[45]: 

work_out[46]: 


8: Rechteck mit abgerundeten Ecken 

9: ausgefülltes, abgerundetes Rechteck 

10: justierter Grafiktext 

Liste möglicher Attribute der Grafikgrundfunktionen: 

0: Linie 

1: Marker 

2: Text 

3: ausgefüllter Bereich 

4: kein Attribut 

Farbdarstellungs-Flag (0 nicht verfügbar, 1 verfügbar) 
Textrotations-Flag (0 nicht verfügbar, 1 verfügbar) 

Flächenfüllung (0 nicht verfügbar, 1 verfügbar) 

Flag für die Funktion CELLARRAY (0 nicht verfügbar, 1 verfügbar) 

Anzahl aller verfügbaren Farben oder 

0: mehr als 32767 Farben (kontinuierliche Verteilung) 

2: monochrom 

Kennzeichnung für Grafik-Cursor-Kontrolle 
0: keine 

1: Tastatur (allein) 

2: Tastatur und anderes Gerät (Maus) 

Eingabegerät für variierende Eingaben 

0: keine 

1: Tastatur 

2: anderes Gerät 

Auswahltasten 

0: keine 

1: Funktionstasten auf der Tastatur 

2: anderes Tastenfeld 

alphanumerische Eingabe (String) 

0: keine 

1: Tastatur 

Ein-/Ausgabegerät-Typ 
nur Ausgabe 
nur Eingabe 
Ein-/Ausgabe 
reserviert 
Metafile-Ausgabe 
geringste Zeichenbreite 

geringste Zeichenhöhe bzgl. der Y-Achse des verwendeten Koordinaten¬ 
systems (Abstand zwischen Baseline und Topline) 
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work_out[47]: 

work_out[48]: 

work_out[49]: 

work_out[50]: 

work_out[51]: 

work_out[52]: 

work_out[53]: 

work_out[54]: 

work_out[55]: 

work_out[56]: 


größte Zeichenbreite 

größte Zeichenhöhe bzgl. der Y-Achse des verwendeten Koordinaten¬ 
systems (Abstand zwischen Baseline und Topline) 
geringste Linienbreite bzgl. der X-Achse des verwendeten Koordinaten¬ 
systems 
immer 0 

größte Linienbreite bzgl. der X-Achse des verwendeten Koordinaten¬ 
systems 
immer 0 

geringste Markerbreite bzgl. der X-Achse 
geringste Markerhöhe bzgl. der X-Achse 
größte Markerbreite bzgl. der X-Achse 
größte Markerhöhe bzgl. der X-Achse 


Bemerkungen 

contrl[6] ist hier ein Ausgabeparameter, der für die anderen Funktionen als Eingabeparameter 
benötigt wird. Die geringste Zeichenbreite und -höhe bezeichnet die effektive Zeichengröße, 
nicht die der Box mit Platz etwa für Unterstreichung. 


Vergleiche auch Anhang, dort sind die speziellen Werte des ST aufgeführt sowie “EXTENDED 
1NQUIRE FUNCTION” (VDI102). 


Zusätzliche Funktion für Matrixdrucker - es kann die maximale Auflösung angegeben 
werden: 

ptsin[0]: maximale X-AuflÖsung 

ptsin[l]: maximale Y-Auflösung 

contrl[l]: auf 1 setzen 


Zusätzliche Funktion für den Atari-Page-Printer - die Adresse des internen Buffers wird 
zurückgeliefert: 

contrl[0]: High-Word der Adresse 

contrl[l]: Low-Word der Adresse 


Standardattribute: 


Attribut 

Standardwert 

VDI-Funktion 

Zeichenhöhe 

nominelle Zeichenhöhe 

vst_height 

Basislinienwinkel 

OGrad 

vst_rotation 

Textausrichtung 

links, Basislinie 

vst_alignment 
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Attribut 

Standardwert 

VDI-Funktion 

Texteffekt 

normal 

vst_effects 

Linienstärke 

nominelle Linienstarke 

vst_width 

Markergröße 

nominelle Markergröße 

vsmjheight 

Aussehen der Linienenden 

rechteckig 

vsl_ends 

Schreibmodus 

Replace 

vswr_mode 

Eingabemodus 

REQUEST (alle Eingabegeräte) 

vsinjnode 

Umrahmung 

sichtbar 

vsf_perimeter 

frei definierbares Linienmuster 

durchgehend 

vsl_udsty 

frei definierbares Füllmuster 

Logo des Herstellers 

vsf_udpat 

Cursor 

versteckt 

v_show_c und 
v_hide_c 

Clipping 

abgeschaltet 

vs_clip 


Standardfarben: 


Index 

Farbe 

Bezeichnung 

0 

weiß 

WHITE 

1 

schwarz 

BLACK 

2 

rot 

RED 

3 

grün 

GREEN 

4 

blau 

BLUE 

5 

cyan 

CYAN 

6 

gelb 

YELLOW 

7 

magenta 

MAGENTA 

8 

hellgrau 

LWHITE 

9 

dunkelgrau 

LBLACK 

10 

dunkelrot 

LRED 

11 

dunkelgrün 

LGREEN 

12 

dunkelblau 

LBLUE 

13 

dunkelcyan 

LCYAN 

14 

dunkelgelb 

LYELLOW 

15 

dunkelmagenta 

LMAGENTA 

darüber: 

geräteabhängig 
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CLOSE WORKSTATION (VDI2) 


Mit “CLOSE WORKSTATION” wird das mit “OPEN WORKSTATION” geöffnete Ein-/ 
Ausgabegerät geschlossen und jede weitere Ausgabe zu diesem Gerät unterbunden. Es muß 
unbedingt darauf geachtet werden, daß vor Benutzung von “CLOSE WORKSTATION” alle 
virtuellen Workstations geschlossen werden. 

CLOSE WORKSTATION bewirkt auf den genannten Gerätetypen folgende Ereignisse: 

Bildschirm Umschaltung in den Alphamodus 

Plotter Update 

Drucker Update (falls nicht unmittelbar vorher einer stattgefunden hat) 

Metafile Datei wird ordnungsgemäß geschlossen 

Kamera Update 


Deklaration in C: 

void v_clswk (WORD handle) 

{ 

contrl[0] = 2; 
eontrl[l] = contrl[3) = 0; 
contrl[6] = handle; 
vdi (); 

} 


GEM-Arrays: 


Adresse 

Felddement 

Belegung 

contrl 

contrl[0] 

2 

Opcode für V CLSWK 

contrl+2 

contrlfl] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+12 

contrl [6] 

handle 

Gerätekennung 
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OPEN VIRTUAL SCREEN WORKSTATION (VDI100) 


Es wird ein virtuelles Ausgabegerät auf einem bereits geöffneten physikalischen Ausgabegerät 
geöffnet. Das entsprechende Gerät muß zuvor mit “OPEN WORKSTATION” geöffnet 
worden sein. Sinn und Zweck des Ganzen ist, daß mehrere Programme gleichzeitig das Gerät 
benutzen können, ohne einander in die Quere zu kommen (zum Beispiel das eigene Programm 
und die AES). Auch innerhalb eines Programmes kann es sinnvoll sein, mit mehreren 
Workstations gleichzeitig zu arbeiten - beispielsweise wenn man zwischen zwei häufig 
benutzten Mengen von Attributen hin- und herschalten möchte. 


Diese Funktion ist nur für den Bildschirmtreiber definiert. Die Gerätekennung der aktuellen 
physikalischen Bildschirm-Workstation muß man beim AES mit “grafJiandleO” erfragen! 

Das VDI besitzt keinen Mechanismus, um die Eingabegeräte bei mehreren virtuellen 
Workstations zu verwalten. Diese Aufgabe muß die Applikation übernehmen, die die 
physikalische Bildschirm-Workstation öffnet. 

In den TOS-Versionen 1.00,1.04,1.06,1.62 und 2.05 gibt es einen Fehler bei der Verwaltung 
der virtuellen Workstations: Folge kann sein, daß Handles mehrfach vergeben werden, so daß 
unvermittelt Workstation-Attribute verstellt werden. Dies passiert genau dann, wenn in der 
Bildschirmtreiber-intemen Workstation-Liste “Lücken” entstehen. Einzige Abhilfe: das 
Programm “VDIFIX” von Karsten Isakovic im AUTO-Ordner installieren (man bekommt es 
direkt vom Autor, in den meisten Mailboxen und unter Umständen auch beim Fachhändler). 

Deklaration in C: 

void v_opnvwk (WORD *work_in, WORD *handle, WORD *work_out) 

{ 

iioff = work_in; 
iooff = work_out; 
pooff = work__out+45; 
contrl[0] = 100; 
contrl[l] = 0; 

contrl[3] = 11; contrl[6] = *handle; 

vdi (); 

*handle = contrl[6]; 
iioff = intin; 
iooff = intout; 
pooff = ptsout; 

} 





338 


ATARI Profibuch 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

100 

Opcode für V.OPNVWK 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

6 

# Einträge in ptsout 

contrl+6 

contrl [3] 

11 

# Einträge in intin 

contrl+8 

contrl[4] 

45 

# Einträge in intout 

contrl+12 

contrl [6] 

handle Gerätekennung 

intin 

intin[0..10] 

workjn[0..10] 

intout 

intout[0..44] 

work_out[0..44] 

ptsout 

ptsout[0..11] 

work_out[45..56] 


Bemerkungen 

Die Ein- und Ausgabeparameter sind mit denen von OPEN WORKSTATION (VDI 1) 
identisch. 

contrI[6] ist beim Aufruf die Nummer der physikalischen Workstation, auf der die virtuelle 
Workstation geöffnet werden soll. Bei der Rückkehr enthält contrl[6] die Nummer der 
geöffneten Workstation oder den Fehlercode 0. 

“v_opnvwk()” alloziert Speicher, weshalb bei Accessories Vorsicht geboten ist. Um Proble¬ 
men vorzubeugen, sollte eine virtuelle Workstation von einem Accessory möglichst sofort 
geöffnet und nie geschlossen werden. 
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CLOSE VIRTUAL SCREEN WORKSTATION (VDI101) 


Mit “CLOSE VIRTUAL SCREEN WORKSTATION” wird das mit “OPEN VIRTUAL 
SCREEN WORKSTATION” geöffnete virtuelle Ein-/Ausgabegerät geschlossen und jede 
weitere Ausgabe zu diesem Gerät unterbrochen. 

Vorsicht! Wenn beim Öffnen der Workstation ein Fehler aufgetreten ist, darf man diese 
Funktion nicht aufrufen! 


Deklaration in C: 

void v_clsvwk (WORD handle) 

{ 

contrl[0] = 101; 
contrl[l] = contrl[3] = 0; 
contrir6] = handle; 
vdi (); 

1 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

101 

Opcode für V_CLSVWK 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+12 

contrl [6] 

handle 

Gerätekennung 
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CLEAR WORKSTATION (VDI3) 


Mit “CLEAR WORKSTATION” wird der Bildschirm gelöscht und auf die ausgewählte 
Hintergrundfarbe (Index 0 in der Farbtabelle) gesetzt. Analog wird bei einem Plotter der Puffer 
gelöscht und bei einem Drucker zusätzlich ein Seitenvorschub durchgeführt. Bei einem 
Metafile wird lediglich der Opcode gespeichert, bei einer Kamera wird die Ausgabe gelöscht 
und die Hintergrundfarbe gesetzt. Ein Aufruf von “OPEN WORKSTATION” löscht das 
Display (Bildschirm o. ä.) automatisch. 


Deklaration in C: 

void v_clrwk (WORD handle) 

{ 

contrl[0] = 3; 
contrl[l] = contrl[3] = 0; 
contrl[6] = handle; 
vdi (); 

} 


GEM-Arrays: 


Adresse 

Feidelement 

Belegung 

contrl 

contrl [0] 

3 

Opcode für V_CLRWK 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrI+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+12 

contrl[6] 

| handle Gerätekennung 
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UPDATE WORKSTATION (VDI4) 


“UPDATE WORKSTATION” wird benötigt, um einem Ein-/Ausgabegerät mitzuteilen, alle 
gepufferten Grafikkommandos auszuführen. 


Auf einem Bildschirm wird diese Funktion nicht benötigt, da die Grafikkommandos hier 
umgehend ausgeführt werden (sie ist im ROM auch nicht implementiert). So speichern bei¬ 
spielsweise Druckertreiber die Kommandos in einem Puffer (wird beim Druckertreiber auch 
“Display-List” genannt). 

Die Ausgabe über diese Geräte erfolgt erst nach Aufruf der “UPDATE WORKSTATION”- 
Funktion. Ist der Pufferfür das Ausgabegerätgeleert,kehrtdie “UPDATEWORKSTATION”- 
Funktion zurück. Zu beachten ist hierbei, daß bei einem Drucker kein Seitenvorschub gegeben 
wird. Bei einem Metafile wird lediglich der Opcode in den Metafile-Puffer geschrieben. 


Deklaration in C: 

void v_updwk (WORD handle) 

{ 

contrl[0] = 4; 

contrl[1] = contrl[3] = 0; 

contrl[6] = handle; 

vdi (); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

4 

Opcode für V_UPDWK 

contrl+2 

contrl [1] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+12 

contrl [6] 

handle 

Gerätekennung 


Bemerkungen 

Zusätzliche Funktion für Druckertreiber: Statt der aktuellen Seite kann ein eigener Buffer auf 
dem Drucker ausgegeben werden. 
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contrl[3] = 2; /* zwei Werte in intin[] */ 
intin[0] /* High-Word der Anfangsadresse */ 

intin[l] /* Low-Word der Anfangsadresse */ 

contrl[l] = 1; /* Buffer nicht löschen */ 
contrl[0] = 4; 
contrl[6] = handle; 
vdi (); ... 

Zusätzliche Funktion für die Atari-SLM-Laserdrucker: In intout[0] wird der Status des 

Druckers zurückgeliefert. 


intout[0] 

Fehler 

0 

NO ERROR 

2 

PRINTER NOT READY 

3 

TONER EMPTY 

5 

PAPER EMPTY 
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LOAD FONTS (VDI119) 


Mit dieser Funktion kann man zusätzlich zu den fest installierten System zeichensätzen weitere 
Zeichensätze laden. Als Ergebnis erhält man die Zahl der hinzugekommenen Zeichensätze 
(wenn man also “vst_load_fonts()” für eine Workstation mehrfach aufruft, erhält man keine 
weiteren Zeichensätze und daher als Ergebnis eine 0). 

Für diese Funktion muß GDOS installiert sein (“vq_gdos()” benutzen!), sonst gibt es bedauer¬ 
licherweiseeinen Systemabsturz. Die zusätzlichen Zeichensätze müssen in der ASSIGN.SYS- 
Datei vermerkt sein. Daß “vstjoad.J'ontsO” ohne GDOS nicht funktioniert, hat einen guten 
Grund. GDOS selbst benutzt nämlich diesen Funktionsaufruf, um die Zeichensatzheader an 
den entsprechenden Gerätetreiber weiterzuleiten. Ohne GDOS dient diese Funktion also zur 
Installation bereits geladener GEM-Zeichensätze. Nur mit GDOS ist sie für Anwenderpro¬ 
gramme interessant. 

Und so lädt man auf korrekte Art und Weise Zeichensätze: 

1. Nach “v_opnvwk()” die Anzahl der Systemzeichensätze (aus work_outf 10]) merken. 

2. Mit “vq_gdos()” sicherstellen, daß “vst_load_fonts()” aufgerufen werden darf. 

3. Den Return-Wert zur Zahl der Systemzeichensätze addieren. Damit hat man die Gesamt¬ 
zahl der Zeichensätze. 

4. Für alle Zeichensatznummem von 1 bis zur Gesamtzahl “vqt„name()” aufrufen. Damit 
erfährt man den Zeichensatznamen und den Zeichensatzindex, unter dem man den Zei¬ 
chensatz später abrufen kann. 

5. Am Ende des Programms “vst_unload_fonts()” nicht vergessen! 

Deklaration in C: 

WORD vst_load_fonts (WORD handle, WORD select) 

{ 

contrl(0] = 119; 
contrl[l] = 0; 
contrl[3] = 1; 
contrl[6] = handle; 
intin[0] = select; 
vdi (); 

return intout[0]; 


} 
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GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

119 

Opcode für VST_LOAD_FONTS 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

1 

# Einträge in intin 

contrl+8 

contrl [4] 

1 

# Einträge in intout 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

intin 

intout 

intin [0] 
intoutfO] 

select 

Retum-Wert 


Parameter: 

select: 0 (reserviert für zukünftige Benutzung) 

vst_load_fonts(): Anzahl der zusätzlich verfügbaren Zeichensätze 

Bemerkungen 

“vst Joad_fonts()” kann Speicher allozieren, daher ist bei Accessories Vorsicht geboten. Um 
Problemen vorzubeugen, 1 sollte die Funktion entweder nicht oder sofort nach dem Start 
aufgerufen werden. 
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UNLOAD FONTS (VDI120) 


Durch “UNLOAD FONTS” werden die durch “vst_load_fonts()” geladenen Zeichensätze 
wieder entfernt. Da die Zeichensätze nur einmal pro physikalische Workstation geladen 
werden, werden sie natürlich erst dann wieder aus dem Speicher entfernt, wenn alle 
“benutzenden” Workstations (beim Bildschirm also die verschiedenen virtuellen) 
“vst_unload_fonts()” aufgerufen haben. 

Die Systemzeichensätze bleiben von dieser Funktion unberührt. 

Deklaration in C: 

void vst_unload_fonts (WORD handle, WORD select) 

{ 

intin[0] = select; 
contrl[0] = 120; 
contrl[l] = 0; 
contrl[3) = 1; 
contrl[6] = handle; 
vdi <); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0J 

120 

Opcode für VST_UNLOAD_FONTS 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

1 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin[0] 

select 



Parameter: 

select: 0 (reserviert für zukünftige Benutzung) 
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SET CLIPPING RECTANGLE (VDI129) 


MitdieserFunktionwirdein Arbeitsbereichfestgelegt oder freigegeben. Wird ein Arbeitsbereich 
festgelegt, so werden alle Grafikoperationen auf diesen Bereich beschränkt. Überstehende 
Bereiche werden abgeschnitten. Wenn man kein Clip-Rechteck setzt, wird auch an den Bild¬ 
schirmgrenzen nicht geclippt! 

Deklaration in C: 

void vs__clip (WORD handle, WORD clip_flag, WORD *pxyarray) 

{ 

pioff = pxyarray; 
intintO] = clip_flag; 
contrl[0] = 129; 
contrl[1] = 2; 
contrl[3] = 1; 
contrl[6] = handle; 
vdi (); 

pioff = ptsin; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

129 

Opcode für VS_CLIP 

contrl+2 

contrlfl] 

2 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

1 

# Einträge in intin 

contrl+8 

contrlf4] 

0 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin[0] 

clip_flag 

ptsin 

ptsin[0..3] 

pxyarray[0.,3] 


Parameter: 

clip_flag: 

pxyarray[0]: 

pxyarray[l]: 

pxyarray[2]: 

pxyarray[3J: 


0: Clippen des Arbeitsbereichs aus 

1: Clippen des Arbeitsbereichs ein 

X-Koordinate des Eckpunktes 

Y-Koordinate des Eckpunktes 

X-Koordinate der diagonal gegenüberliegenden Ecke 

Y-Koordinate der diagonal gegenüberliegenden Ecke 
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Ausgabefunktionen 

|~ POLYLINE (VDI6) 


Diese Funktion dient dazu, einen Polygonzug zu zeichnen. 

Die Koordinaten des ersten Punktes bestimmen den Startpunkt des Linienzuges. Nacheinan¬ 
der werden dann alle Punkte durch eine Linie verbunden. 

Einzelne Punkte können durch ein einzelnes Koordinatenpaar nicht gezeichnet werden, je¬ 
doch durch eine Linie der Länge Null, also zwei gleiche Koordinatenpaare. 

Die Linienattribute und die Einstellung des Schreibmodus werden berücksichtigt. 


Deklaration in C: 

void vjoline (WORD handle, WORD count, WORD *pxyarray) 

{ 

pioff = pxyarray; 
contrl[0] = 6; 
contrl[l] = count; 
contrl[3] = 0; 
contrl[6] = handle; 
vdi (); 

pioff = ptsin; 

1 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

6 

Opcode für V_PLINE 

contrl+2 

contrl[l] 

count (n) 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

ptsin 

ptsin[0..2n-l] 

pxyarray[0. 

.2n-l] 
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Parameter: 

pxyarray[0]: 

pxyarray[l]: 

pxyarray[2]: 

pxyarray[3]: 


X-Koordinate des ersten Punktes 
Y-Koordinate des ersten Punktes 
X-Koordinate des zweiten Punktes 
Y-Koordinate des zweiten Punktes 


pxyarray[2n-2]: X-Koordinate des letzten (n-ten) Punktes 

pxyarray[2n-l]: Y-Koordinate des letzten (n-ten) Punktes 
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POLYMARKER (VDI7) 


Diese Funktion zeichnet Marker an vorgegebene Stellen. Die Markerattribute und der 
eingestellte Schreibmodus werden benutzt. 

Anwendung finden die Marker etwa bei grafischer Darstellung von Statistiken. 


Deklaration in C: 

void vjomarker (WORD handle, WORD count, WORD *pxyarray) 
{ 

pioff = pxyarray; 
contrl[0] = 7; 
cont r1[1] = count; 
contrl[3] = 0; 
contrl[6] = handle; 
vdi () ; 

pioff = ptsin; 

} 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

7 

Opcode für V_PMARKER 

contrl+2 

contrl[l] 

count (n) 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

eontrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

ptsin 

ptsin[0..2n-l] 

pxyarray [0. 

•2n-l] 


Parameter: 

count: 

pxyarray [0]: 
pxyarray[l]: 
pxyarray [2]: 


Anzahl der Marker 
X-Koordinate des ersten Markers 
Y-Koordinate des ersten Markers 
X-Koordinate des zweiten Markers 






350 


ATARI Profibuch 


pxyarray[3]: 


pxyarray[2n-2]: 

pxyarray[2n-l]: 


Y-Koordinate des zweiten Markers 


X-Koordinate des letzten (n-ten) Markers 
Y-Koordinate des letzten (n-ten) Markers 
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TEXT (VDI8) 


Diese Funktion schreibt einen Text auf den Grafikbildschirm. 

Das Koordinatenpaar bestimmt die Position des Textes. Der Text wird linksjustiert ausgege¬ 
ben. Die Basislinie liegt in Richtung der X-Achse, wird also in der Höhe durch die Y-Koor- 
dinate bestimmt. Der Text kann durch diverse Attribute auch anders ausgerichtet werden. 
Jedes einzelne Zeichen (Character) wird durch die Bits 0...7 bestimmt. Die Textattribute und 
der Schreibmodus werden berücksichtigt. 

Man kann die Ausgabegeschwindigkeit beschleunigen, wenn man folgende Punkte beachtet: 

- auf Bytegrenzen justiert ausgeben (das nützt natürlich nur bei acht Pixel breiten, nicht- 
proportionalen Zeichensätzen etwas) 

- möglichst ohne Clipping ausgeben 

- beim Systemzeichensatz (allgemein: bei nichtproportionalen, acht Pixel breiten Zei¬ 
chen) im Replace-Modus und ohne Clipping ausgeben, ansonsten den TRANSPA- 
RENT-Modus wählen. 

Ein C-Binding benötigt einen Byte-orientierten und Null-terminierten, ein Assembler- 
Binding einen Word-orientierten String. Im Zeichensatz fehlende Zeichen werden durch ein 
Ersatzzeichen (im allgemeinen das Fragezeichen) ersetzt. 


Deklaration in C: 

void v_gtext (WORD handle, WORD x, WORD y, const char *string) 
{ 

WORD i; 
ptsin[0] = x; 
ptsin[l] = y; 
i = 0; 

while (intin[i++] = *string++); 

contrl[Q] = 8; 

contrl[l] = 1; 

contrl[3] = -i; 

contrl[6] = handle; 

vdi (); 

} 
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GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

8 

Opcode für V_GTEXT 

contrl+2 

contrl[ 1] 

1 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

n 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin[0..n-l] 

string[0..n-l] 

ptsin 

ptsin [0] 

X 


ptsin+2 

ptsin[l] 

y 



Parameter: 

x: X-Koordinate des Textes 

y: Y-Koordinate des Textes 

string: Zeiger auf auszugebende Zeichenkette 
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FTLLED AREA (VDI 9) 


Diese Funktion füllt eine von einem Polygonzug umrahmte Fläche aus. Dabei werden die 
Füllattribute beachtet. Die ausgefüllte Fläche wird von einer Linie in der Füllfarbe umgeben. 
Änderungen der Attribute bzw. des Schreibmodus sind über die Attributfunktionen möglich. 

Sollte das Ausgabegerät keine Ausfüllmöglichkeit haben, so wird die Fläche nur mit der 
aktuellen Füllfarbe umgeben. Es müssen mindestens drei Koordinatenpaare übergeben wer¬ 
den. Eine Nullfläche (nur ein Koordinatenpaar) wird nur dann als Punkt gezeichnet, wenn die 
automatische Umrahmung der Fläche (siehe SET FILL PERIMETER VISEBILITY) einge¬ 
schaltet ist. 

Eine Linie wird nicht ausgegeben. Offene Polygonzüge werden selbsttätig geschlossen. 


Deklaration in C: 

void v_fillarea (WORD handle, WORD count, WORD *pxyarray) 
{ 

pioff -- pxyarray; 
contrl[0] = 9; 
contrlfl] = count; 
contrl(3] = 0; 
contrl[6] = handle; 
vdi (); 

pioff = ptsin; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

' 9 

Opcode für VFILLAREA 

contrl+2 

contrl(l] 

count (n) 

# Einträge in ptsin 

contri+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

ptsin 

ptsin[0..2n-l] 

pxyarray [0..2n-l] 
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Parameter: 

courtt: 

pxyarray[0] 

pxyarray[l] 

pxyarray[2] 

pxyarray[3] 


Anzahl der Punkte 
X-Koordinate des ersten Punktes 
Y-Koordinate des ersten Punktes 
X-Koordinate des zweiten Punktes 
Y-Koordinate des zweiten Punktes 


pxyarray[2n-2]: X-Koordinate des letzten (n-ten) Punktes 

pxyarray[2n-l]: Y-Koordinate des letzten (n-ten) Punktes 
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CELL ARRAY (VDI10) 


Diese Funktion erlaubt einen komplexeren Farbaufbau des Bildschirms. Die Farbe der 
gesetzten Pixel (nicht ganzer Objekte wie Linien) ist ortsabhängig und nicht, wie sonst üblich, 
objektabhängig. Ein frei definierbares Rechteck wird in einzelne Teile - Zellen - durch Zeilen 
und Spalten unterteilt. Jeder dieser Zellen wird eine Farbe zugeordnet, die für die Pixelfarbe 
zuständig ist. Werden nun die Zellen beschrieben, so erscheinen die gesetzten Pixel in der 
Farbe, die für die jeweilige Zelle bestimmt wurde. Diese Funktion ist im ROM-Bildschirmtreiber 
nicht implementiert. 


Deklaration in C: 

void v_cellarray (WORD handle, WORD *pxyarray, WORD row_length, 
WORD el_used, WORD num_rows, WORD wrt_mode, 
WORD *colarray) 

( 

iioff = colarray; 
pioff = pxyarray; 
contrl[0] = 10; 
contrl[l] = 2; 

contrl[3] = row_lenght*num_rows; 
contrl[6] = handle; 
contrl[7] = row_length; 
contrl[8] = el_used; 
contrl[9] = num__rows; 
contrl[10] = wrt_mode; 
vdi (); 

iioff = intin; 
pioff = ptsin; 

} 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

10 

Opcode für VCELLARRAY 

contrl+2 

contrl[l] 

2 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

n 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 
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Adresse 

Feldelement 

Belegung 

contrl+12 

contrl[6] 

handle Gerätekennung 

contrl+14 

contrl[7] 

rowjength 

contrl+16 

contrl[8] 

el_used 

contrl+18 

contrl[9] 

num_rows 

contrl+20 

contrl[10] 

wrt_mode 

intin 

intin[0..n-l] 

colarray[0..n-l] 

ptsin 

ptsin[0..3] 

pxyarray[0..3] 


Parameter: 


rowjength: Zeilenlänge im Farbindexarray 
el_used: Zonenanzahl pro Zeile (also Spaltenanzahl) 

numjrows: Anzahl der Zeilen 
wrtjmode: Schreibmodus 
colarray[0] bis 

colarray[n-l]: Farbindexarray, enthält die Farbinformation zeilenweise 
pxyarray[0]: X-Koordinate der unteren linken Ecke des Begrenzungsrechteckes 
pxyaiTay[l]: Y-Koordinate der unteren linken Ecke des Begrenzungsrechteckes 
pxyarray[2]: X-Koordinate der oberen rechten Ecke des Begrenzungsrechteckes 
pxyarray[3]: Y-Koordinate der oberen rechten Ecke des Begrenzungsrechteckes 


Bemerkungen 

n ist hier die # Zeilen * # Spalten der Zellenaufteilung. Hat man etwa ein Feld von horizontal 
zehn und vertikal vier Zellen, so sind dies zehn Spalten und vier Zeilen. 


Somit ist n = 4 * 10 = 40. 
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CONTOÜK FILL (VDI103) 


Diese Funktion füllt eine Fläche abhängig vom Staitpunkt aus. Die Füllfläche wird durch den 
Bildschirmrand oder durch eine definierte Farbe begrenzt. Die aktuellen Füllattribute werden 
beachtet. Einige Ausgabegeräte unterstützen diese Funktion nicht (kann mit “vq_extnd()” 
erfragt werden). 


Deklaration in C: 

void v_contourfill (WORD handle, WORD x, WORD y, WORD Index) 

{ 

intin[0] = index; 

ptsin[0] = x; 

ptsin [1J =■ y; 

contrl[0] = 103; 

contrl[l] = contrl[3] = 1; 

contrl[6] = handle; 

vdi (); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

103 Opcode für V_CONTOURFILL 

contrl+2 

contrl[l] 

1 # Einträge in ptsin 

contrl+4 

contrl[2] 

0 # Einträge in ptsout 

contrl+6 

contrl[3j 

1 # Einträge in intin 

contrl+8 

contrl[4] 

0 # Einträge in intout 

contrl+12 

contrl[6] 

handle Gerätekennung 

intin 

intin[0] 

index 

ptsin 

ptsin[0] 

X 

ptsin+2 

ptsinfl) 

y 


Parameter: 

index: Farbindex (bei negativem Parameter wird gefüllt, bis ein andersfarbiges Pixel ange¬ 
troffen wird) 

x: X-Koordinate des Startpunktes 

y: Y-Koordinate des Startpunktes 
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FILL RECTANGLE (VDI 114) 



Diese Funktion füllt ein Rechteck unter Beachtung der Attribute (ähnlich “FELLED AREA” 
(VDI 9)) aus, ohne “Perimeter” (Umrahmungseinstellung) zu berücksichtigen. 

Deklaration in C: 

void vr_recfl (WORD handle, WORD *pxyarray) 

{ 

pioff = pxyarray; 
contrl[0] = 114; 
contrl[l] = 2; 
contrl[3] = 0; 
cont r1[6] = handle; 
vdi (); 

pioff = ptsin; 

1 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrlfö] 

114 

Opcode für VR_RECFL 

contrl+2 

contrl[l] 

2 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

ptsin 

ptsinf0..3] 

pxyarray [0.. 3] 


Parameter: 


pxyarray[0]: 
pxyarrayfl]: 
pxyarray[2]: 
pxyarray [3]: 


X-Koordinate des Eckpunktes 

Y-Koordinate des Eckpunktes 

X-Koordinate der diagonal gegenüberliegenden Ecke 

Y-Koordinate der diagonal gegenüberliegenden Ecke 


Bemerkungen 

Vorsicht : Nicht auf allen Ausgabegeräten verfügbar! Im Zweifel besser “v_bar()” benutzen! 
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GENERALIZED DRAWING PRIMITIVE (VDI11) (GDP) 


Die GDP-Funktion erlaubt eine einfache Handhabung einer Reihe von Grafikgrundfunktionen. 
Diezehn möglichen Grafikgrundfunktionen sind in der Reihenfolge ihrer Identifikationsnummer 
aufgefiihrt. 

Einige der Funktionen sind nicht auf allen Ausgabegeräten verfügbar. 
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BAR (VDI11, GDP1) 

Die Funktion BAR zeichnet ein ausgefülltes Rechteck. Benutzt wird die Grundfunktion etwa 
für Balkendiagramme. Die Füllattribute sowie der Schreibmodus werden berücksichtigt. 

Deklaration in C: 

void vjoar {WORD handle, WORD *pxyarray) 

{ 

pioff = pxyarray; 
contrl[0] = 11; 
contrl[l] - 2 -, 
contrl[3] = 0; 
contrl[5] = 1; 
contrl[6] = handle; 
vdi {); 

pioff = ptsin; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

11 

Opcode für GDP 

contrl+2 

contrl[l] 

2 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

eontrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

1 

VJBAR 

contrl+12 

contrl[6] 

handle Gerätekennung 

ptsin 

ptsin[0..3] 

pxyarray[0..3] 


Parameter: 

pxyarrayfüj: X-Koordinate des Eckpunktes 

pxyarray[1 ]: Y-Koordinate des Eckpunktes 

pxyarray[2]: X-Koordinate der diagonal gegenüberliegenden Ecke 

pxyarray[3]: Y-Koordinate der diagonal gegenüberliegenden Ecke 
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ARC (VDI11, GDP 2) 

Die Funktion ARC zeichnet einen Kreisbogen, Es werden die Linienattribute, “Perimeter” 
(Umrahmung), der Sehreibmodus und die tatsächliche Pixelgröße berücksichtigt. 

Der Bogen wird entgegen dem Uhrzeigersinn (positiv) gezeichnet. Nulldurchgänge sind 
durchaus möglich. Die Angabe des Radius bezieht sich auf die X-Achse. 

Die Winkelmessung erfolgt in 1/10 Grad: 


900 



2700 


Deklaration in C: 

void v_arc (WORD handle, WORD x, WORD y, WORD radius, WORD begang, 
WORD endang) 

{ 

ptsin[0] = x; 
ptsin[1] = y; 

ptsin[2] = ptsin[3] = ptsin[4) = ptsin[5] = 0; 

ptsin[6] = radius; 

ptsin[7] = 0; 

intin[0] = begang; 

intin[l] = endang; 

contrl[0] = 11; 

contrl[l] - 4; 

contrl[3] = contrl[5] = 2; 

cont r1[6] = handle; 

vdi (); 

} 
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GEM-Arrays: 


Adresse 

Feldelement 

contrl 

contrl[0] 

contrl+2 

contrl[l] 

contrl+4 

contrl [2] 

contrl+6 

contrl [3] 

contrl+8 

contrl [4] 

contrl+10 

contrl[5] 

contrl+12 

contrl[6] 

intin 

intin[0] 

intin+2 

intin[l] 

ptsin 

ptsinfOl 

ptsin+2 

ptsin[l] 

ptsin+4 

ptsin[2..5] 

ptsin+12 

ptsin[6] 

ptsin+14 

ptsin[7] 


Belegung 


11 Opcode für GDP 

4 # Einträge in ptsin 

0 # Einträge in ptsout 

2 # Einträge in intin 

0 # Einträge in intout 

2 V_ARC 

handle Gerätekennung 

begang 

endang 

x 

y 

o 

radius 

0 


Parameter: 


begang: 

endang: 

x: 

y: 

radius: 


Startwinkel für den Bogen (0..3600) 
Endwinkel für den Bogen (0..3600) 
X-Koordinate für den Mittelpunkt 
Y-Koordinate für den Mittelpunkt 
Radius (bzgl. der X-Achse) 
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Die FunktionPIESLICE zeichnet einen Kreisflächenausschnitt, wie er auch für Tortengrafiken 
benutzt wird. Es werden die Füllattribute, der Schreibmodus und das Pixelgrößenverhältnis 
berücksichtigt. Der Kreisflächenausschnitt wird entgegen dem Uhrzeigersinn beginnend 
beim Startwinkel und endend beim Endwinkel gezeichnet, wobei der Radius an der X-Achse 
gemessen wird. Nulldurchgänge sind durchaus möglich. 

Die Winkel werden in 1/10 Grad gemessen: 


900 



2700 


Deklaration in C: 

void v_pieslice (WORD handle, WORD x, WORD y, WORD radius, 
WORD begang, WORD endang) 

{ 

ptsin[0] = x; 
ptsin[1] = y; 

ptsin[2] = ptsin[3] = ptsin[4] = ptsin[5] = 0; 

ptsin[6] = radius; 

ptsin[7] = 0; 

intin[0J = begang; 

intinfl] = endang; 

contrl[0] = 11; 

contrlfl] = 4; 

contrl[3] = 2; 

contrl[5] = 3; 

contrl[6] = handle; 

vdi {); 

} 






364 


ATARI Profibuch 


GEM-Arrays: 


Adresse 

Feldelement 

contrl 

contrl[0] 

contrl+2 

contrl[l] 

contrl+4 

contrl [2] 

contrl+6 

contrl [3] 

contrl+8 

contrl[4] 

contrl+10 

contrl[5] 

contrl+12 

contrl[6] 

intin 

intin[0] 

intin+2 

intinfl] 

ptsin 

ptsin[0] 

ptsin+2 

ptsin[I] 

ptsin+4 

ptsin[2..5] 

ptsin+12 

ptsin[6] 

ptsin+14 

ptsin[7] 


Belegung 


11 Opcode für GDP 

4 # Einträge in ptsin 

0 # Einträge in ptsout 

2 # Einträge in intin 

0 # Einträge in intout 

3 V_PIESLICE 
handle Gerätekennung 

begang 

endang 

x 

y 

o 

radius 

0 


Parameter: 


begang: 

endang: 

x: 

y: 

radius: 


Startwinkel für den Kreisausschnitt (0..3600) 
Endwinkel für den Kreisausschnitt (0..3600) 
X-Koordinate für den Mittelpunkt 
Y-Koordinate für den Mittelpunkt 
Radius (bzgl. der X-Achse) 




VDI-Betriebssystemroutinen 


365 


CIRCLE (VDI11, GDP 4) 


Die FunktionCIRCLEzeichneteineKreisfläche.Es werden die Füllattribute, der Schreibmodus 
und das Pixelgrößenverhältnis berücksichtigt. Der Radius wird anhand der X-Achse be¬ 
stimmt. 


Deklaration in C: 

void v_circle (WORD handle, WORD x, WORD y, WORD radius) 
{ 

ptsin[0] = x; 
ptsin[1] = y; 
ptsin[2] = ptsin[3] = 0; 
ptsin[4] = radius; 
ptsin [5] = 0; 
contrl[0] = 11; 
contrl[1] = 3; 
contrl[3] = 0; 
contrl[5] = 4; 
contrl[6] = handle; 
vdi (); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

11 OpcodefürGDP 

contrl+2 

contrl[l] 

3 # Einträge in ptsin 

contrl+4 

contrl [2] 

0 # Einträge in ptsout 

contrl+6 

contrl [3] 

0 # Einträge in intin 

contrl+8 

contrl [4] 

0 # Einträge in intout 

contrl+10 

contrl[5] 

4 V_CIRCLE 

contrl+12 

contrl [6] 

handle Gerätekennung 

ptsin 

ptsin [0] 

X 

ptsin+2 

ptsin[l] 

y 

ptsin+4 

ptsin[2..3] 

0 

ptsin+8 

ptsin [4] 

radius 

ptsin+10 

ptsin[5] 

0 
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Parameter: 

x: X-Koordinate für den Mittelpunkt 

y: Y-Koordinate für den Mittelpunkt 

radius: Radius (bzgl. der X-Achse) 
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ELLIPSE (VDIII, GDP 5) 


Die Funktion ELLIPSE zeichnet eine Ellipsenfläche. 

Die Ftillattribute und der Schreibmodus werden berücksichtigt. Das Pixelgrößenverhältnis 
wird ignoriert; der Radius für die X- und Y-Achse ist getrennt zu übergeben. 


Deklaration in C: 


void v_ellipse 
{ 


(WORD handle, WORD x, WORD y, 
WORD yradius) 


ptsin[0] = x; 
ptsin[1] = y; 
ptsin[2] = xradius; 
ptsin[3] = yradius; 
contrl[0] = 11; 
contrl[1] = 2; 
contrl[3] = 0; 
contrl[5] = 5; 
contrl[6] = handle; 
vdi (); 


WORD xradius. 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

11 Opcode für GDP 

contrl+2 

contrl[l] 

2 # Einträge in ptsin 

contrl+4 

contrl[2] 

0 # Einträge in ptsout 

contrl+6 

contrl[3] 

0 # Einträge in intin 

contrl+8 

contrl[4] 

0 # Einträge in intout 

contrl+10 

contrl [5] 

5 V_ELLIPSE 

contrl+12 

contrl[6] 

handle Gerätekennung 

ptsin 

ptsinfO] 

X 

ptsin+2 

ptsinfl] 

y 

ptsin+4 

ptsin[2] 

xradius 

ptsin+6 

ptsin[3] 

yradius 
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Parameter: 

x: X-Koordinate für den Mittelpunkt 

y: Y-Koordinate für den Mittelpunkt 

xradius: Radius der Ellipse in X-Richtung 
yradius: Radius der Ellipse in Y-Richtung 
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ELLIPTICAL ARC (VDI11, GDP 6) 

Die Funktion ELLIPTICAL ARC zeichnet einen Ellipsenbogenausschnitt. Die Linienattribute 
und der Schreibmodus werden berücksichtigt. 

Das Pixelgrößenverhältnis wird ignoriert, die Radien in X- und Y-Richtung sind also getrennt 
zu übergeben. Die Ausgabe der Ausschnitts erfolgt entgegen dem Uhrzeigersinn vom 
Anfangs- bis zum Endwinkel. 

Die Winkel werden in 1/10 Grad gemessen: 


900 



2700 


Deklaration in C: 

void v_ellarc (WORD handle, WORD x, WORD y, WORD xradius, 
WORD yradius, WORD begang, WORD endang) 

{ 

ptsin[0] = x; 
ptsin[l] ~ y; 
ptsin[2] = xradius; 
ptsin[3] = yradius; 
intinfO] = begang; 
intin[l] = endang; 
contrl[0] = 11; 
contrl[l] = contrl[3] = 2; 
contrl[5] = 6; 
contrl[6] = handle; 
vdi (); 

} 
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GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

11 Opcode für GDP 

contrl+2 

contrl[l] 

2 # Einträge in ptsin 

contrl+4 

contrl[2] 

0 # Einträge in ptsout 

contrl+6 

contrl[3] 

2 # Einträge in intin 

contrl+8 

contrl [4] 

0 # Einträge in intout 

contrl+10 

contrl[5] 

6 VJELLARC 

contrl+12 

contrl[6] 

handle Gerätekennung 

intin 

intin[0] 

begang 

intin+2 

intinfl] 

endang 

ptsin 

ptsin[0] 

X 

ptsin+2 

ptsinfl] 

y 

ptsin+4 

ptsin[2] 

xradius 

ptsin+6 

ptsin[3] 

yradius 


Parameter: 

begang: Startwinkel für den Ellipsenbogen (0..3600) 

endang: Endwinkel für den Ellipsenbogen (0..3600) 

x: X-Koordinate für den Mittelpunkt 

y: Y-Koordinate für den Mittelpunkt 

xradius: Radius der Ellipse in X-Richtung 

yradius: Radius der Ellipse in Y-Richtung 
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ELLIPTICAL PIE (VDI11, GDP 7) 


Die Funktion ELLIPTICAL PIE zeichnet einen Ellipsenflächenausschnitt, wie er auch für 
Tortengrafiken benutzt werden kann. Es werden die Füllattribute und der Schreibmodus 
berücksichtigt. 

Das Pixelgrößenverhältnis wird ignoriert, die Radien in X- und Y-Richtung sind folglich ge¬ 
trennt zu betrachten. Der Ausschnitt wird vom Anfangs- bis zum Endwinkel entgegen dem 
Uhrzeigersinn ausgegeben. 

Die Winkel werden in 1/10 Grad gemessen: 


900 


1800 


0 


2700 


Deklaration in C: 

void v_ellpie (WORD handle, WORD x, WORD y, WORD xradius, 
WORD yradius, WORD begang, WORD endang) 


ptsin[0] = x; 
ptsin[1] = y; 
ptsin[2) = xradius; 
ptsin [3] = yradius; 
intin[0] = begang; 
intin[l] = endang; 
contrl[0] = 11; 
contrl[l] = contrl[3] = 2; 
contrl[5] = 7; 
contrl[6] = handle; 
vdi (); 
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GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

11 Opcode für GDP 

contrl+2 

contrl[l] 

2 # Einträge in ptsin 

contrl+4 

contrl [2] 

0 # Einträge in ptsout 

contrl+6 

contrl[3] 

2 # Einträge in intin 

contrl+8 

contrl[4] 

0 # Einträge in intout 

contrl+10 

contrl [5] 

7 V_ELLPIE 

contrl+12 

contrl[6] 

handle Gerätekennung 

intin 

intinfO] 

begang 

intin+2 

intin[l] 

endang 

ptsin 

ptsin[0] 

X 

ptsin+2 

ptsin[l] 

y 

ptsin+4 

ptsin[2] 

xradius 

ptsin+6 

ptsin[3] 

yradius 


Parameter: 


begang: 

endang: 

x: 

y: 

xradius: 

yradius: 


Startwinke] für den Ellipsenausschnitt (0..3600) 
Endwinkel für den Ellipsenausschnitt (0..3600) 
X-Koordinate für den Mittelpunkt 
Y-Koordinate für den Mittelpunkt 
Radius der Ellipse in X-Richtung 
Radius der Ellipse in Y-Richtung 
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ROUNDED RECTANGLE (VDI11, GDP 8) 

Die Funktion ROUNDED RECTANGLE zeichnet ein Rechteck mit abgerundeten Ecken. Es 
werden die Linienattribute, der Schreibmodus und das Pixelgrößenverhältnis (bezüglich der 
Bögen) berücksichtigt. 

Deklaration in C: 

void v_rbox (WORD handle, WORD *xyarray) 

{ 

pioff = pxyarray; 
contrl[0] = 11; 
contrl[1] = 2; 
contrl[3] = 0; 
contrl[5] = 8; 
contrl[6] = handle; 
vdi (); 

pioff = ptsin; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

11 

Opcode für GDP 

contrl+2 

contrlfl] 

2 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

8 

V_RBOX 

contrl+12 

contrl[6] 

handle Gerätekennung 

ptsin 

ptsin[0..3] 

xyarray[0.,3] 


Parameter: 

xyarray[0]: X-Koordinate des Eckpunktes 
xyarray[l]: Y-Koordinate des Eckpunktes 
xyarray[2]: X-Koordinate der diagonal gegenüberliegenden Ecke 
xyarray[3]: Y-Koordinate der diagonal gegenüberliegenden Ecke 
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FILLED ROUNDED RECTANGLE (VDI11, GDP 9) 

Die Funktion FILLED ROUNDED RECTANGLE zeichnet ein ausgefülltes Rechteck mit 
abgerundeten Ecken. Es werdenFüllattribute, der Schreibmodus und das Pixelgrößenverhältnis 
(bezüglich der Bögen) berücksichtigt. 

Deklaration in C: 

void v_rfbox (WORD handle, WORD *xyarray) 

{ 

pioff = xyarray; 
contrl[0] = 11; 
contrl[l] = 2; 
contrl[3] = 0; 
contrl[5] = 9; 
contrl[6] = handle; 
vdi 0; 

pioff = ptsin; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

11 

Opcode für GDP 

contrl+2 

contrlf 1 j 

2 

# Einträge in ptsin 

eontrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrlf 5] 

9 

vjrfbox 

contrl+12 

contrlfö] 

handle 

Gerätekennung 

ptsin 

ptsin[0..3] 

xyarray[0..3] 


Parameter: 

xyarray [0]: X-Koordinate des Eckpunktes 

xyarrayfl]: Y-Koordinate des Eckpunktes 

xyarray[2]: X-Koordinate der diagonal gegenüberliegenden Ecke 

xyarray[3]: Y-Koordinate der diagonal gegenüberliegenden Ecke 
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JUSTIF1ED GRAPHICS TEXT (VDI11, GDP10) 


JUSTIFIED GRAPHICS TEXT erlaubt die wenig aufwendige Ausgabe eines Textes, genauer 
einer Zeichenkette. 

Der Text wird links und rechts bezogen auf den Startpunkt und die Länge justiert. Um den Text 
auf die erforderliche Länge zu bringen, hat man die Wahl zwischen Dehnung der Wort- und/ 
oder Zeichenzwischenräume. 

Die Ausdehnung kann auch unterbleiben. Es werden die Textattribute und der Schreibmodus 
berücksichtigt. 

Bei einem C-Binding ist der String Byte-orientiert und Null-terminiert, bei einem Assembler- 
Binding Word-orientiert 

Im Zeichensatz fehlende Zeichen werden durch ein Ersatzsymbol (meist ein Fragezeichen) 
ersetzt. 


Deklaration in C: 


void v_justified 
{ 

WORD *tmp; 


(WORD handle, WORD x, WORD y, const CHAR *String, 
WORD length, WORD word_space, WORD char__space) 


ptsin[0] = x; 
ptsin[l] = y; 
ptsin[2] = length; 
ptsin[3] = 0; 
intin[0] = word_space; 
intin(l) = char_space; 
tmp = &(intin[2]); 
while (*tmp++=*string++) ; 
contrl[0] = 11; 
contrl(l] = 2; 

contrl[3] = (int)(tmp-&(intin))-1; 
contrl[5] = 10; 
cont r1[6] = handle; 
vdi (); 







376 


ATARI Profibuch 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

11 Opcode für GDP 

contrl+2 

contrl[l] 

2 # Einträge in ptsin 

contrl+4 

contrl[2] 

0 # Einträge in ptsout 

contrl+6 

contrl[3] 

n+2 # Einträge in intin 

contrl+8 

contrl[4] 

0 # Einträge in intout 

contrl+10 

contrl[5] 

10 V_JUSTIFIED 

contrl+12 

contrl[6] 

handle Gerätekennung 

intin 

intin [0] 

word_space 

intin+2 

intin[l] 

char_space 

intin+4 

intin[2..n+l] 

string[0,.n-l] 

ptsin 

ptsin[0] 

X 

ptsin+2 

ptsin[l] 

y 

ptsin+4 

ptsin [2] 

length 

ptsin+6 

ptsin[3) 

0 


Parameter: 


word_space: 


char_space: 


String: 

x: 

y: 

length: 


Flag für Woitzwischenräume 

0: keine Dehnung der Wortzwischenräume 

nicht 0: Dehnung der Wortzwischenräume 

Flag für Zeichenzwischenräume 

0: keine Dehnung der Zeichenzwischenräume 

nicht 0: Dehnung der Zeichenzwischenräume 

Zeiger auf Zeichenkette 

X-Koordinate des Textausrichtungspunktes 

Y-Koordinate des Textausrichtungspunktes 

Textlänge (bzgl. der X-Achse) 
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Attributfunktionen 


SET WRITING MODE (VDI32) 


SET WRITING MODE bestimmt, auf welche Art und Weise Quellpixel (also zum Beipiel die 
aktuelle Linienfarbe) und Zielpixel (also der aktuelle Hintergrund) verknüpft werden, um die 
resultierenden Farbwerte zu ermitteln. Normaler Schreibmodus ist der REPLACE-Modus. 

Die Anzahl der verfügbaren Schreibmodi erhält man über die Funktion EXTENDED 
INQUIRE FUNCTION. 


Deklaration in C: 


WORD vswr_mode (WORD handle, 
{ 


intin[0] - mode; 
contrl[0] = 32; 
contrl[l] = 0; 
contrl[3] = 1; 
contrl[6] = handle; 
vdi (); 

return intout[0]; 


WORD mode) 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrlfO] 

32 

Opcode für VSWR_MODE 

contrl+2 

contrl [1] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

o 

# Einträge in ptsout 

contrl+6 

contrl [3] 

1 

# Einträge in intin 

contrl+8 

contrl[4] 

1 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin[0] 

mode 


intout 

intout[0] 

Return-Wert 
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Parameter: 

mode: Schreibmodus 

MD_REPLACE (1): Replace 

MD_TRANS (2): Transparent 

MD_XOR (3): XOR 

MD_ERASE (4): Reverse Transparent 

vswr_mode(): ausgewählter Schreibmodus (bei Wahl eines ungültigen Parameters wird 

der Replace-Modus gesetzt) 

Die Verknüpfungen der Schreibmodi: 

Folgende Bezeichnungen werden benutzt: 

Maske: Grafikobjekt (Linie, Füllmuster, Grafiktext, Marker) 

Vom: Vordergrundfarbe des neuen Grafikobjektes 

Hinten: Hintergrundfarbe des neuen Grafikobjektes 

Alt: gegenwärtige Farbe 

Neu: resultierende Farbe 

Die Erfahrung zeigt, daß man die Unterschiede zwischen den verschiedenen Modi am besten 
anhand eines Beispiels versteht. Daher lehnen wir uns in den folgenden Ausführungen an das 



Abb. 3.3: Die Verknüpfungen der Schreibmodi 
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“GEM Programmier-Handbuch” (ebenfalls bei SYBEX erschienen, mittlerweile leider aber 
nicht mehr erhältlich) an. 

In der fol genden Beschreibung der Verknüpfungen gehen wir von der in Abbildung 3.3 gezeig¬ 
ten Sachlage aus: der Hintergrund ist in eine schwarze und eine weiße Hälfte geteilt. Auf die¬ 
sem Hintergrund wird nun die rechts gezeigte Figur ausgegeben. Die gemusterten Flächen ste¬ 
hen für gesetzte Bits, die weißen für nicht gesetzte. Die folgenden vier Beispiele zeigen die 
Auswirkungen der verschiedenen Verknüpfungen: 

MDJREPLACE 

Diese Darstellungsart ist einfach zu verstehen. Wenn das VDI ein Bild ausgibt, überschreibt 
es den Hintergrund mit der Vordergrundfarbe, wenn das entsprechende Bit gesetzt ist, oder 
es setzt ein weißes Pixel, wenn das Bit 0 ist. Die logische Verknüpfung lautet: 

Neu :*= (Vorn AND Maske) OR (Hinten AND NOT maske) . 

Um das Ganze auf Papier und Bleistift zu übertragen: zunächst malt man die Figur auf weißes 
Papier, schneidet sie dann aus und klebt den Schnipsel dann auf die Grafik. 

MDJTRANS 

Bei der transparenten Darstellung ignoriert das VDI alle Bits der zu zeichnenden Form, die 
auf 0 gesetzt sind, und gibt lediglich die Bits aus, die gesetzt sind. Die logische Verknüpfung 
lautet: 

Neu := (Vorn AND Maske) OR (ALT AND NOT Maske) 

Und wieder die Papieranalogie: dieser Modus entspricht dem Ersetzen, nur daß man auf 
durchsichtige Folie zeichnet. 

MD_XOR 

Diese Darstellungsart eignet sich vorzüglich für das Zeichnen von Figuren, die ohne Änderung 
des Hintergrunds wieder gelöscht oder bewegt werden sollen. Die Bits der Hintergrunds und 
der zu zeichnenden Figur werden mit einem Exklusiv-ODER (XOR) verknüpft, Diese 
Verknüpfung hat eine sehr interessante Eigenschaft. 

Wenn Sie die Figur eine zweites Mal in der Darstellungsart XOR ausgeben, ist die Figur 
plötzlich wieder verschwunden. Der Grund hierfür liegt in der Tatsache, daß die XOR- 
Verknüpfung eines Bits mit sich selbst den inversen Wert ergibt. 

Sie können diese Darstellungsart für einfache Animationen wie eine Gummibox einsetzen. 
Auch bewegte Objekte können auf diese Art und Weise gezeichnet werden: 
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1. Das Objekt einmal ausgeben. 

2. Das gleiche Objekt erneut ausgeben (nun ist es wieder verschwunden). 

3. Objekt verändern (Größe, Position). 

4. Zurück zu Schritt 1. 


Die logische Verküpfung für MD_XOR: 

Neu:= (Maske XOR Alt) 

Man beachte, daß das Resultat völlig unabhängig von der eingestellen Ausgabefarbe ist! 



Abb.3.4: Der XOR-Modus 
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In Farbauflösungen werden, wie auch im monochromen Modus, die Pixelwerte exklusiv- 
oderiert, jedoch ist der Effekt schwerer vorherzusehen. Im XOR-Modus werden die Bits 
gemäß der gemalten Figur mit XOR logisch verknüpft, unabhängig von der Farbe des Musters 
oder der gemalten Figur! 

Beispielsweise wird aus einem Pixelwert (bei vier Farbebenen) 0x1011 in Verbindung mit 
XOR 0x0100. Vor allem ist damit klar, daß aus Schwarz Weiß wird und umgekehrt. Alles 
andere ist nicht fest definiert. Stehen vier Farben zur Verfügung (beispielsweise niedrige ST- 
Auflösung), so wird aus Rot durch XOR Grün und umgekehrt. Stehen jedoch 16 Farben zur 
Verfügung (beispielsweise mittlere TT-Auflösung), so wird aus Rot Dunkelcyan und aus Grün 
Dunkelmagenta! Der monochrome Modus ist folglich nur ein (sehr einfacher) Spezialfall! 

MD_ERASE (“Reverse Transparent”) 

Bei der invers transparenten Darstellung werden nur die auf 0 gesetzten Pixel des zu 
zeichnenden Bildes berücksichtigt (im Gegensatz zur transparenten Darstellung). Alle nicht 
gesetzten Bits werden beim Zeichnen in der Vordergrundfarbe ausgegeben. 

Diese Darstellungsart bietet einige interessante Einsatzmöglichkeiten. Sie können die trans¬ 
parente und die invers transparente Darstellung gemeinsam benutzen, um beispielsweise eine 
zweifarbige unterbrochene Linie oder Text mit einer zusätzlichen Hintergrundfarbe erschei¬ 
nen zu lassen. 

In beiden Fällen geben Sie die Figur erst in der transparenten Darstellung mit einer 
Vordergrundfarbe aus, ändern dann die Vordergrundfarbe und geben die Figur ein zweites Mal 
mit invers transparenter Darstellung aus. 

Die logische Verknüpfung für MD_ERASE: 


Neu := (Alt ÄND Maske) OR (Vorn AND NOT Maske) 
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Diese Funktion wählt die Farbintensität zu den einzelnen Farbregistem. Gewählt wird mit 
einer Intensität der RGB-Farben (Rot, Grün, Blau) zwischen 0 und 1000 (Promille). Sollte eine 
ungültige Farbnummer übergeben werden, so werden die erreichbaren Werte angenommen, 
also bei negativen Werten 0 und bei zu großen Werten 1000. 


Üblicherweise verfügt nicht jedes Ausgabegerät über 1000 mögliche Farbabstufungen. 
Folglich sind für verschiedene Eingabe-Intensitäten der RGB-Farben die tatsächlich einge¬ 
stellten Intensitäten gleich. Die Anzahl der Farbindizes ist geräteabhängig und kann beim 
Öffnen der (virtuellen) Workstation abgefragt werden. 


SET COLOR REPRESENTATION kann nur benutzt werden, wenn “Lookup-table”-Unter- 
stützung vorhanden ist (anderenfalls gibt es ja keine Farbregister, die man setzen könnte). 


Deklaration in C: 

void vs_color (WORD handle, WORD index, WORD *rgb_in) 
! 

WORD i; 

infin[0] = index; 
for (i=l; i<4; i++) 

intin[i] = *rgb_in++; 
contrl[0] = 14; 
contrl[lj = 0; 
contrl[3] = 4; 
contrl[6] = handle: 
vdi (); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

14 

Opcode für VS_COLOR 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

4 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+12 

contrl [6] 

handle Gerätekennung 
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Adresse 

Feldelement 

Belegung 

intin 

intin [0] 

index 

intin+2 

intin[1..3] 

rgb_in[0..2] 


Parameter: 


index: 

rgbJntO]: 

rgb_in[l]: 

rgb_in[2]: 


Farbnummer (die ersten 16 Farbnummem werden vom AES benutzt 
und sollten deshalb nicht verändert werden!) 

Farbintensität von Rot 
Farbintensität von Grün 
Farbintensität von Blau 


Tabelle der VDI-Standardfarben: 


Index 

Farbe 

Bezeichnung 

0 

weiß 

WHITE 

1 

schwarz 

BLACK 

2 

rot 

RED 

3 

grün 

GREEN 

4 

blau 

BLUE 

5 

cyan 

CYAN 

6 

gelb 

YELLOW 

7 

magenta 

MAGENTA 

8 

hellgrau 

LWHITE 

9 

dunkelgrau 

LBLACK 

10 

dunkelrot 

LRED 

11 

dunkelgrün 

LGREEN 

12 

dunkelblau 

LBLUE 

13 

dunkelcyan 

LCYAN 

14 

dunkelgelb 

LYELLOW 

15 

dunkelmagenta 

LMAGENTA 

darüber: 

geräteabhängig 
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SET POLYLINE LINE TYPE (VDI15) 

Diese Funktion wählt die (Polyline-)Liniendarstellung aus. Die Anzahl der verfügbaren 
Darstellungen ist quasi unbegrenzt. Sechs Linienformen sind für alle Geräte fest vorgegeben. 
Weitere sind geräteabhängig bzw. können selbst definiert werden. 

Ist ein gewählter Linientyp nicht verfügbar, so wird der Linientyp “durchgezogen” (oder 
genauer: LTJSOLID) gewählt. Bei der Benutzung dickerer Linien wird unter Umständen auf 
den Defaulttyp gewechselt und auch der Schreibmodus verändert. 

Die entsprechenden Verfügbarkeiten bei dem Ausgabegerät können mit EXTENDED 
INQUIRE FUNCTION abgefragt werden. 

Deklaration in C: 

WORD vsl_type (WORD handle, WORD style) 

{ 

intin[0] = style; 
contrl[0] = 15; 
contrl[l] = 0; 
contrl[3] = 1; 
contrl[6] = handle; 
vdi (); 

return intout[0]; 

1 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

15 

Opcode für VSLJTYPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

I 

# Einträge in intin 

contrl+8 

contrl [4] 

1 

# Einträge in intout 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

intin 

intout 

intinfO] 

intout[0] 

style 

Retum-Wert 
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Parameter: 

style: Linienstil (1 = gesetztes Pixel, 0 = nicht gesetztes Pixel), 16 Bits 


style 

LTJSOLID (1) 
LTJLONGDASH (2) 
LT_DOTTED (3) 
LT_DASHDOT (4) 
LT_DASHED (5) 
LT_DASHDOTDOT (6) 
LT_USERDEF (7) 

8 und mehr 

vsl_type(): ausgewählter Linienstil 


MSB LSB 

1111111111111111 (durchgehend) 
1111111111110000 (langer Strich) 
1110000011100000 (Punkte) 
1111111000111000 (Strich, Punkt) 
1111111100000000 (Strich) 

1111000110011000 (Strich, Punkt, Punkt) 
frei definierbar (Default: LT_SOLID) 
abhängig vom Ausgabegerät 
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SET USER-DEFINED LINE STYLE PATTERN (VDI113) 


Mit dieser Funktion kann der siebte (frei definierbare) Linientyp von SET POLYLINE LINE 
TYPE (VDI 15) festgelegt werden. Als erster Punkt der Linie wird das höchstwertige Bit des 
16-Bit-Wortes gewählt. Standardwert ist eine durchgezogene Linie. 


Deklaration in C: 


void vsl__udsty (WORD handle, WORD pattem) 

{ 


} 


intin[0] 
contrl[0] 
contrl[1] 
contrl[3] 
contrl[6] 
vdi (); 


= pattern; 
= 113; 

» 0 ; 

= i; 

= handle; 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

113 

Opcode für VSLJJDSTY 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

1 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin[0] 

pattem 



Parameter: 

pattem: Linienmuster als 16-Bit-Wort 
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SET POLYLINE LINE WIDTH (VDI16) 

Mit dieser Funktion wählt man die Linienbreite. Die Funktion ist nicht auf allen Ausgabegeräten 
einsetzbar. Die gesetzte Breite ist kleiner oder gleich der gewählten Breite. Eine Korrektur der 
Breite seitens der Funktion kann nötig sein, wenn kein passender Wert (eine ungerade Zahlen) 
übergeben wurde. Die Breite der Linie bezieht sich immer auf Koordinaten in X-Richtung. 

Deklaration in C: 

WORD vsl_width (WORD handle, WORD width) 

{ 

ptsin[0] = width; 
ptsin[1] = 0; 
contrl [0] = 16; 
contrl[1] = 1; 
contrl[3] = 0; 
contrl[6] = handle; 
vdi (); 

return ptsout[0 J; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

16 

Opcode für VSLWIDTH 

contrl+2 

contrl[l] 

1 

# Einträge in ptsin 

contrl+4 

contrl[2] 

1 

# Einträge in ptsout 

contrl+6 

contrl [3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

ptsin 

ptsinfO] 

width 


ptsin+2 

ptsin[l] 

0 


ptsout 

ptsout[0] 

Return-Wert 

ptsout+2 

ptsout[l] 

0 



Parameter: 

width: Linienbreite (nur ungerade Werte ab 1; bei falscher Wahl wird die nächstkleinere 

mögliche Linienbreite gewählt) 

vsl_width(): ausgewählte Linienbreite (bezüglich der X-Achse) 
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SET POLYLINE COLOR INDEX (VDI17) 

Mit dieser Funktion kann die Linienfarbe gewählt werden. Die zwei Standardindizes 0 und 
1 sind auf allen Geräten verfügbar. Weitere hängen vom Ausgabegerät ab. 

Deklaration in C: 

WORD vsl_color (WORD handle, WORD color_index) 

{ 

intin[0] = color_index; 
contrl[0] =17; 
contrl[1] = 0; 
contrl[3] = 1; 
contrl[6] = handle; 
return intout[0]; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

17 Opcode für VSL_COLOR 

contrl+2 

contrl[ 1 ] 

0 # Einträge in ptsin 

contrl+4 

contrl [2] 

0 # Einträge in ptsout 

contrl+6 

contrl[3] 

1 # Einträge in intin 

contrl+8 

contrl [4] 

1 # Einträge in intout 

contrl+12 

contrl[6] 

handle Gerätekennung 

intin 

intin[0] 

colorjndex 

intout 

intout [0] 

Return-Wert 


Parameter: 

colorjndex: Linienfarbe 

vsLcolor(): ausgewählte Linienfarbe (bei ungültigem Farbindex: I) 
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SET POLYLINE END STYLES (VDI108) 


Mit dieser Funktion wird das Aussehen der Linienenden gewählt. Das normale Aussehen der 
Enden ist ein eckiger Linienabschluß. 


Zusätzlich gibt es noch abgerundete Enden oder Enden mit Pfeilspitzen. Auch ein ganzer 
Polygonzug wird als Linie betrachtet. Das Ende der Linie ist bei der Pfeilspitze in der Spitze, 
bei dem abgerundeten Ende jedoch im Zentrum des (Halb-)Kreises, der das Ende darstellt. 



Abb. 3.5: Die verschiedenen Linien-Endsiile 


Deklaration in C: 

void vsl_ends (WORD handle, WORD beg_style, WORD end_style) 
{ 

intin[0] = beg_style; 
intinfl] = end_style; 
contrlfö] = 108; 
contrl[l] = 0; 
contrl[3] = 2; 
contrl[6] = handle; 
vdi (); 

} 
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GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

108 

Opcode für VSL_ENDS 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3j 

2 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

intin 

intin[0] 

beg_style 

intin+2 

intin[I] 

end_style 


Parameter: 

beg_style: Aussehen des Linienendes am Anfangspunkt der Linie. 

LE_SQUARED(0): eckig 
LE_ARROWED (1): Pfeilform 
LE_ROUNDED (2): abgerundet 
end_style: analog mit dem Endpunkt 
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SET POLYMÄRKER TYPE (VDI18) 


Mit dieser Funktion kann das Aussehen der Marker ausgewählt werden, von denen es 
mindestens die aufgeführten sechs gibt. Bei Übergabe einer ungültigen Nummer wird der 
dritte Typ gewählt. Der erste Typ (der Punkt) kann in der Größe nicht verändert werden. 



Abb. 3.6: Die Markertypen 


Deklaration in C: 

WORD vsm_type (WORD handle, WORD symbol) 
{ 

intin[0] = symbol; 
contrl[0] = 18; 
contrl[l] = 0; 
contrl[3] - 1 ; 
contrl[6] = handle; 
vdi (); 

return int out[0]; 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

18 

Opcode für VSM_TYPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl [3] 

1 

# Einträge in intin 

contrl+8 

contrl [4] 

1 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin[0] 

symbol 


intout 

intout[0] 

Return-Wert 
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Parameter: 

symbol: 


vsm_type(): 


Markertyp 

MT_DOT (I): Punkt 

MT_PLUS (2): Plus 

MT_ASTERISK (3): Sternchen 
MT_SQUARE (4): Quadrat 

MT_DCROSS (5): Kreuz 

MT_DIAMOND (6): Raute 


über 7: geräteabhängig 

ausgewählter Markertyp (bei falschen Eingabewerten wird MT_ASTERISK 
gewählt) 
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SET POLYMARKER HEIGHT (VDI19) 

Mit dieser Funktion kann die Markerhöhe (außer bei Typ 1) bezüglich der Y-Achse gewählt 
werden, wobei die Breite angepaßt wird. 

Bei Angabe einer ungültigen (zu großen) Höhe wird die nächstkleinere gewählt. Die Anzahl 
der verfügbaren Höhen wird beim Öffnen der (virtuellen) Workstations zurückgegeben. 

Deklaration in C: 

WORD vsm_height (WORD handle, WORD height) 

1 

ptsin[0] = 0; 
ptsin[l] = height; 
contrl[0] = 19; 
contrl[l] = 1; 
contrl[3] = 0; 
contrl[6] = handle; 
vdi () ; 

return ptsout [1]; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

19 Opcode für VSMJHEIGHT 

contrl+2 

contrl[l] 

1 # Einträge in ptsin 

contrl+4 

contrl[2] 

1 # Einträge in ptsout 

contrl+6 

contrl[3] 

0 # Einträge in intin 

contrl+8 

contrl [4] 

0 # Einträge in intout 

contrI+12 

contrl[6] 

handle Gerätekennung 

ptsin 

ptsin [0] 

0 

ptsin+2 

ptsinfl] 

height 

ptsout 

ptsout[0] 

set_height_x 

ptsout+2 

ptsoutfl] 

Return-Wert 
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Parameter: 

height: 

set_height_x: 


Markerhöhe bzgl. Y-Richtung (bei falscher Wahl wird die nächstkleine¬ 
re mögliche Größe gewählt) 

ausgewählte Markerhöhe bzgl. X-Richtung (das Pixelgrößenverhältnis 
wird berücksichtigt); bei PC-GEM erhält man lediglich eine 0 als Rück¬ 
gabeweit 


vsm_height(): 


ausgewählte Markerhöhe bzgl. Y-Richtung 
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Mit dieser Funktion wählt man die Farbe der Marker. ZweiFarbindizes (Ound 1) sind auf jeden 
Fall verfügbar, weiterehängen von dem jeweiligen Ausgabegerät ab. Ein ungültiger Farbindex 
wird durch den Index 1 ersetzt. 


Deklaration in C: 

WORD vsm_color (WORD handle, WORD color_index) 
{ 

intin[0] = color_index; 
contrl[0] = 20; 
contrl[l] = 0; 
contrl[3] = 1; 
contrl[6] = handle; 
vdi (); 

return intout[0]; 

1 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

20 Opcode für VSM_COLOR 

contrl+2 

contrl[l] 

0 # Einträge in ptsin 

contrl+4 

contrl [2] 

0 # Einträge in ptsout 

contrl+6 

contrl[3] 

1 # Einträge in intin 

contrl+8 

contrl [4] 

1 # Einträge in intout 

contrl+12 

contrl[6] 

handle Gerätekennung 

intin 

intin [0] 

colorjndex 

intout 

intout[0] 

Return-Wert 


Parameter; 

colorjndex; gewünschte Markerfarbe 

vsm_color(): ausgewählte Markerfarbe (1 bei ungültigem Farbindex) 
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SET CHARACTER HEIGHT, ABSOLUTE MODE (VDI12) 


Mit dieser Funktion kann die absolute Zeichenhöhe, von der Basislinie bis zur Zeichenzellen¬ 
obergrenze, bestimmt werden. Ist die gewünschte Zeichenhöhe nicht verfügbar, so wählt SET 
CHARACTER HEIGHT die nächstkleinere verfügbare. 

Es wird die größte Zeichen- und Zellenbreite zurückgegeben. Sie ist somit insbesondere bei 
Proportionalfonts gleich der Breite des breitesten Zeichens. 

Bei nicht proportionalen Schriften sind logischerweise alle Zeichen gleich breit. 


Deklaration in C: 

void vst__height (WORD handle, WORD height, WORD *charjwidth, 
WORD *char_height, WORD *cell_width, 

WORD *cell_height) 

{ 

ptsin[0] = 0; 
ptsin[l] = height; 
contrl[0] = 12; 
contrl[l] = 1; 
contrl[3] = 0; 
contrl[6] = handle; 
vdi () ; 

*char_width = ptsout[0]; 

*char_height = ptsout[1]; 

*cell_width = ptsout[2]; 

*cell_height = ptsout[3]; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

12 

Opcode für VST_HEIGHT 

contrl+2 

contrl[l] 

1 

# Einträge in ptsin 

contrl+4 

contrl [2] 

2 

# Einträge in ptsout 

contrl+6 

contrl [3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 








VDI-Betriebssystemroutinen 


397 


Adresse 

Feldelement 

Belegung 

ptsin 

ptsin[0] 

0 

ptsin+2 

ptsin[l] 

height 

ptsout 

ptsout[0] 

char_width 

ptsout+2 

ptsout[l] 

charjieight 

ptsout+4 

ptsout[2] 

cell_width 

ptsout+6 

ptsout[3] 

celljieight 


Parameter: 


height; 

char.width: 

charjieight: 

cell_width: 

cell_height: 


Zeichenhöhe (bei falscher Wahl wird die nächstkleinere mögliche Zeichensatz¬ 
größe eingesetzt) 

ausgewählte Zeichenbreite in NDC/RC-Einheiten bezüglich der X-Achse 
ausgewählte Zeichenhöhe in NDC/RC-Einheiten bezüglich der Y-Achse 
ausgewählte Zeichenzellenbreite in NDC/RC-Koordinaten bezüglich der X- 
Achse 

ausgewählte Zeichenzellenhöhe in NDC/RC-Koordinaten bezüglich der Y- 
Achse 


Bemerkungen 

Die meisten Bildschirmtreiber (auch der im ROM) können bei “vst_height()” vorhandene 
Fonts beliebig verkleinern oder auf das Doppelte vergrößern. 
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SET CHARACTER HEIGHT, POINTS MODE (VDI 107) 


Mit dieser Funktion kann die Zeichenzellengröße - Abstand zweier Basislinien - bestimmt 
werden. Gemessen wird der Abstand in (Drucker-)Point (1/72 Zoll, ungefähr 0,353 mm; dies 
entspricht nicht dem typografischen Punkt mit einer Höhe von ca. 0,38 mm!). 


Ist die gewünschte Zeichenhöhe nicht verfügbar, so wird die nächstkleinere gewählt. Bei pro¬ 
portionalen Zeichensätzen werden für Breite und Höhe die maximal möglichen Werte zurück¬ 
gegeben. 


Deklaration in C: 

WORD vst_point (WORD handle, WORD point, WORD *char_width, 
WORD *char_height, WORD *cell_width, 

WORD *cell_height) 

{ 

intin[0] = point; 
contrl[0J = 107; 
contrl[l] = 0; 
contrl[3] =1; 
contrl[6] = handle; 
vdi (); 

*char_width = ptsout[0]; 

*char_height - ptsout[l]; 

*celljwidth = ptsout[2]; 

*cell_height = ptsout[3]; 
return intout[0]; 

} 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

107 

Opcode für VST_POINT 

contrl+2 

contrlfl] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

2 

# Einträge in ptsout 

contrl+6 

contrl[3] 

1 

# Einträge in intin 

contrl+8 , 

contrl [4] 

1 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 
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Adresse 

Feldelement 

Belegung 

intin 

intin[0] 

point 

intout 

intout[0] 

Retum-Wert 

ptsout 

ptsout[0] 

char_width 

ptsout+2 

ptsout[l] 

char_height 

ptsout+4 

ptsout [2] 

cell_width 

ptsout+6 

ptsout[3] 

cell„height 


Parameter: 


point: 

vstjpoint(): 

char_width: 

charjieight: 

cel]_width: 

cell_height: 


Zeichenzellenhöhe in Point (bei falscher Wahl wird die näcbstkleinere mögli¬ 
che Zeichensatzgröße eingesetzt) 

Ausgewählte Zeichenzellenhöhe in Point 

Ausgewählte Zeichenbreite in NDC/RC-Einheiten bezüglich der X-Achse 
Ausgewählte Zeichenhöhe in NDC/RC-Einheiten bezüglich der Y-Achse 
Ausgewählte Zeichenzellenbreite in NDC/RC-Einheiten bezüglich der X- 
Achse 

Ausgewählte Zeichenzellenhöhe in NDC/RC-Einheiten bezüglich der Y- 
Achse 


Bemerkungen 

Der ROM-Bildschirmtreiber kann vorhandene Zeichensätze jeweils auf die doppelte Größe 
skalieren. Daher ist es nicht ohne weiteres möglich, zwischen “skalierten” und tatsächlich vor- 
handenenFonts zu unterscheiden. DiefolgendeRoutinen ermitteltalle vorhandenen Punktgrößen 
für den aktuell eingestellten Zeichensatz. Sie basiert darauf, daß “vst_point()” im Zweifel die 
nächstkleinere vorhandene Größe wählt: 


/* Anfangsgröße: 999 Punkt */ 

WORD asked_for = 999, got_size; 
got__size = asked_for; 

/* Solange die zuletzt gefundene Größe tatsächlich kleiner oder 
gleich der verlangten ist */ 
while (got_size <= asked_for) 

{ 

/* Versuch: ein Punkt kleiner als der zuletzt gefundene */ 
got_size = vst_point (handle, asked_for, sdummy, sdummy, 

Sduinmy, &dummy); 

printf ("available size: %d\n", got_size); 


} 
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Wenn man feststellt, daß alle Punktgrößen vorhanden sind, liegt offensichtlich ein frei¬ 
skalierbarer Zeichensatz vor (wie etwa bei einem VDI-Postscript-Treiber). In einem solchen 
Fall sollte man dem Anwender nur eine Liste von Standardgrößen anzeigen und die exakte 
Größenangabe über ein Edit-Feld erlauben. 
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Mit dieser Funktion kann die Ausrichtung der Basislinie (für Textausgabe) gewählt werden. 
Gemessen wird in 1/10 Grad. Auf einigen Geräten ist die Funktion nicht oder nur in Teilen 
verfügbar. Der Bildschirmtreiber im ROM unterstützt nur die Rotation in 90-Grad-Schritten. 
SET CHARACTER BASELINE VECTOR nimmt den Winkel, der dem gewünschten am 
nächsten liegt. 


Deklaration in C: 

WORD vst_rotation (WORD handle, WORD angle) 
{ 

intin[0] = angle; 
contrl [0] = 13; 
contrl(1] = 0; 
contrl[3j = 1; 
contrl [6] = handle; 
vdi (); 

return intout[0]; 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

13 

Opcode für VST_ROTATION 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

1 

# Einträge in intin 

contrl+8 

contrl[4] 

1 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intout 

intin[0] 

intout[0] 

angle 

Return-Wert 


Parameter: 

angle: gewünschte Basislinienausrichtung (0..3600) 

vst_rotation(): ausgewählte Basislinienausrichtung 
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SET TEXT FACE (VDI21) 


Diese Funktion wählt - sofern verfügbar - einen Zeichensatz für die nachfolgenden 
Grafiktextausgaben aus. Die Unterstützung der Zeichensätze hängt vom jeweiligen Gerät ab. 
Die Namen und Indizes werden über INQUIRE FACE NAME AND INDEX bestimmt. 


Deklaration in C: 

WORD vst_font (WORD handle, WORD font) 
{ 

intin[0] = font; 
contrl[0] = 21; 
contrlfl] = 0; 
contrl[3] = 1; 
contrl[6] = handle; 
vdi (); 

return intout[0]; 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

21 

Opcode für VST_FONT 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

1 

# Einträge in intin 

contrl+8 

contrl[4] 

1 

# Einträge in intout 

contrl+12 

contri[6] 

handle 

Gerätekennung 

intin 

intout 

intin [0] 
intout [0] 

font 

Return-Wert 


Parameter: 

font: Zeichensatzindex (die konkreten Nummern muß man mittels “INQUIRE 

FACE NAME AND INDEX” abfragen!) 
vst_font(): ausgewählter Zeichensatz 
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SET GRAPHIC TEXT COLOR INDEX (VDI22) 

Mit dieser Funktion kann die Farbe des Textes gewählt werden. Verfügbar sind mindestens 
die Indizes 0 und 1, weitere sind vom jeweiligen Ausgabegerät abhängig. Bei Übergabe eines 
ungültigen Farbindexes wählt SET GRAPHIC TEXT COLOR INDEX den Index 1. 

Deklaration in C: 

WORD vst_color (WORD handle, WORD color_index) 

{ 

intin[0] = colorjndex; 
contrl[0] = 22; 
contrlfl] = 0; 
contrl[3] = 1; 
contrl[6J = handle; 
vdi () ; 

return intout[0]; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

22 

Opcode für VST.COLOR 

contrl+2 

contrlfl] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

1 

# Einträge in intin 

contrl+8 

contrl[4] 

1 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin[0] 

colorjndex 

intout 

intout[0] 

Return-Wert 


Parameter: 

colorjndex: gewünschte Textfarbe 

vst_color(): ausgewählte Textfarbe (1 bei Übergabe eines ungültigen Indexes) 
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SET GRAPHIC TEXT SPECIAL EFFECTS (VDI106) 

Mit dieser Funktion können verschiedene spezielle Texteffekte ausgewählt werden. Es besteht 
die Möglichkeit, diese Effekte untereinander zu vermischen. 

Als Effekte stehen zur Verfügung: 

- fett 
-hell 

- kursiv 

- unterstrichen 

- umrandet, ausgehöhlt 

- schattiert 

- jede Kombination der obengenannten Effekte 

Nicht verfügbare Texteffekte werden nicht gesetzt. Die möglichen Grundeffekte: 


nornal fett hell karslv unterstrichen SffiSSQfeSDDS'S 


Abb. 3.7: Die möglichen Texteffekte 


Deklaration in C: 

WORD vst_effects (WORD handle, WORD effect) 

{ 

intin[0] = effect; 
contrl[0] = 106; 
contrl[l] = 0; 
contrl[3] = 1; 
contrl[6] = handle; 
vdi (); 

return intout[0]; 

} 





VDI-Betriebssystemroutinen 


405 


GEM-Arrays: 


Adresse 

FeldeJement 

Belegung 

contrl 

contrl [0] 

106 

Opcode für VST_EFFECTS 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl [3] 

1 

# Einträge in intin 

contrl+8 

contrl[4] 

1 

# Einträge in intout 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

intin 

intin[0] 

effect 


intout 

intout[0] 

Return-Wert 


Parameter: 


effect: 


gewünschter Texteffekt in Bitdarstellung 

TF_NORMAL 

(0x00): 

normaler Text 

TFTHICKENED 

(0x01): 

Fettschrift 

TF_LIGHTENED 

(0x02): 

helle Schrift 

TF_SLANTED 

(0x04): 

kursive Schrift 

TF_UNDERLINED 

(0x08): 

unterstrichene Schrift 

TF__OUTUNED 

(0x10): 

ausgehöhlte, umrandete Schrift 

TF_SHADOWED 

(0x20): 

schattierte Schrift (im ROM-Treiber nicht 
implementiert) 


vst_effects(): ausgewählter Texteffekt 
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SET GRAPHIC TEXT ALIGNMENT (VDI39) 

Mit dieser Funktion kann die horizontale (bezüglich der Basislinie) und vertikale Ausrichtung 
(senkrecht zur Basislinie) eines Textes bestimmt werden. Horizontal sind drei und vertikal 
sechs Möglichkeiten verfügbar. 

Defaulteinstellung ist der linke Rand der Basislinie (und nicht die untere linke Ecke der linken 
Zeichenzelle). 



Abb. 3.8: Die unterschiedlichen Textausrichtungen 


Deklaration in C: 

void vst_alignment (WORD handle, WORD hor__in, WORD vert_in, 
WORD *hor__out, WORD *vert_out) 

{ 

intin[0] = hor_in; 
intin[l] = vert_in; 
contrl[0] = 39; 
contrl[l] = 0; 
contrl(3] - 2; 
contrl[6] = handle; 
vdi (); 

*hor_out = intout[0]; 

*vert_out = intout[1]; 
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GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

39 

Opcode für VST_ALIGNMENT 

contrl+2 

contrl[ 1 ] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

2 

# Einträge in intin 

contrl+8 

contrl[4] 

2 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin [0] 

horjn 


intin-t-2 

intin[l] 

vert_in 


intout 

intout[0] 

hor_out 

intout+2 

intoutf 1] 

vert_out 


Parameter: 

horjn: horizontale Ausrichtung 

TA_LEFT (0): linksjustiert (default) 

TA_CENTER (1): zentriert 
TA_RIGHT (2): rechtsjustiert 

vert_in: vertikale Ausrichtung 

TA_BASELINE (0): Basislinie (default) 

TA_HALF (1): Halblinie (Oberkante Kleinbuchstaben) 

TA_ASCENT (2): Zeichenoberkante 
TAJ30TTOM (3): Zeichenzellenunterkante 
TA_DESCENT (4): Zeichenunterkante 
TA_TOP (5): Zeichenzellenoberkante 

hor_out: ausgewählte horizontale Ausrichtung 

vert_out: ausgewählte vertikale Ausrichtung 
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SET FILLINTERIOR INDEX (VDI23) 


Mit dieser Funktion wird der Fülltyp ausgewählt. Man hat die Wahl zwischen fünf Typen: leer 
(Hintergrundfarbe), voll (monochrom), Muster, schraffiert, frei definiert. Bei Übergabe eines 
ungültigen Typs wählt SET FILL INTERIOR INDEX den Typ “leer”. 

Deklaration in C: 

WORD vsf_interior (WORD handle, WORD style) 

{ 

intin[0] = style; 
contrl[0] = 23; 
contr.l[l] = 0; 
contrl[3] = 1; 
contrl[6] = handle; 
vdi (); 

return intout[0]; 

1 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrlfO] 

23 

Opcode für VSFJNTERIOR 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrI+6 

contrl[3] 

1 

# Einträge in intin 

Contrl+8 

contrl[4) 

1 

# Einträge in intout 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

intin 

intout 

intin[0] 

intout[0] 

style 

Re tum-Wert 


Parameter: 

style: Gewünschter Fülltyp 

FIS_HOLLOW (0): leer 
FIS_SOLID (1): voll (einfarbig) 

FIS_PATTERN (2): Muster 
FIS_HATCH (3): Schraffur 
FIS_USER (4): frei definierbar 

vsf_interior(): ausgewählter Fülltyp 
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Mit dieser Funktion wird der Musterindex zum Fülltyp ausgewählt. Diese Funktion hat nur 
dann einen Sinn, wenn als Fülltyp nicht leer, einfarbig oder frei definierbar gewählt wurde. 
Nicht verfügbare Indizes werden von SET FELL STYLE INDEX durch den Musterindex 1 
ersetzt. Fülltyp 1, gefolgt von einem beliebigen Musterindex, entspricht immer dem Fülltyp 
2 mit Musterindex 8. Der Index 1 bei Mustern (Typ 2) ist immer das Muster mit der geringsten 
Intensität auf dem Ausgabegerät. Es ist immer monochrom. Hier die Auswahl der Füllmuster 
mit Fülltyp und Musterindex: 



Abb. 3.9: Mögliche Kombinationen von Fülltyp und Musterindex 

Deklaration in C: 

WORD vsf_style (WORD handle, WORD style_index) 
{ 

intin[0] = style_index; 
contrl[0] = 24; 
contrl[l] = 0; 
contrl[3] = 1; 
contrl[6] = handle; 
vdi 0; 

return intout[0]; 


1 
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GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

24 

Opcode für VSFJ3TYLE 

contrl+2 

contrlfl] 

0 

# Einträge in ptsin 

contri+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

1 

# Einträge in intin 

contrl+8 

contrl[4] 

1 

# Einträge in intout 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

intin 

intin[0] 

style_index 

intout 

intout[0] 

Retum-Wert 


Parameter: 

stylc_index: gewünschter Musterindex (bei Mustern oder Schraffuren) 
vsf_style(): ausgewählter Fülltyp (bei Mustern oder Schraffuren) 
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SET FILL COLOR INDEX (VDI25) 

Mit dieser Funktion wird die Fiilifarbe gewählt. Die Farbindizes 0 und 1 sind immer verfügbar, 
weitere hängen von dem Ausgabegerät ab. Ein ungültiger Farbindex wird durch 1 ersetzt. 

Deklaration in C: 

WORD vsf_color (WORD handle, WORD color_index) 

{ 

intim [0] = color_index; 
contrl[0] = 25; 
contrlfl] = 0; 
contrl[3] = 1; 
contrl[6] = handle; 
vdi (); 

return intout[0]; 

1 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

25 Opcode für VSF_COLOR 

contri+2 

contrl[l] 

0 # Einträge in ptsin 

contrl+4 

contrl[2] 

0 # Einträge in ptsout 

contrl+6 

contrl [3] 

1 # Einträge in intin 

contrl+8 

contrl [4] 

1 # Einträge in intout 

contrl+12 

contrl [6] 

handle Gerätekennung 

intin 

intin[0] , 

color_index 

intout 

intout[0] 

Retum-Wert 


Parameter: 

color_index: gewünschte Farbe 
vsf_color(): ausgewählte Farbe 
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Diese Funktion schaltet die automatische Umrahmung der Füllfläche ein oder aus. Der Rand 
wird bei eingeschalteter Umrahmung (default) in der gegenwärtigen Füllfarbe (also im 
allgemeinen nicht in Schwarz!) als durchgehende Linie gezeichnet. 

Deklaration in C: 

WORD vsfjperimeter (WORD handle, WORD per_vis) 

{ 

intim [0] = per_vis; 
contrl[0J = 104; 
contrl[l] = 0; 
contrl[3] = 1; 
contrl[6] = handle; 
vdi (); 

return intout[0]; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

104 

Opcode für VSF. PERIMETER 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 1 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

1 

# Einträge in intin 

contrl+8 

contrl[4] 

1 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin [0] 

per_vis 


intout 

intout[0] 

Retum-Wert 


Parameter: 

perjvis: Flag für Umrahmung (0: keine Umrahmung) 

vsf_perimeter(): eingestellter Modus 

Bemerkungen 

Wird von “vrjecflQ” nicht beachtet. 
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SET USER-DEFINED FILL PATTERN (VDI112) 

Mit dieser Funktion kann das freidefinierbare Füllmuster (“vsf_interior()”, style = 4) festge¬ 
legt werden. 16 jeweils 16-Bit-Worte bestimmen das Füllmuster. Das höchste Bit (15) des er¬ 
sten Wortes entspricht der oberen linken Ecke des Füllmusters, das niedrigste Bit (0) des letz¬ 
ten Wortes der unteren rechten Ecke. Für jede Farbebene wird ein eigenes Füllmuster angelegt. 
Bei einer einzelnen Ebene entspricht ein gesetztes Bit der durch die Füllfarbe bestimmten 
Farbe, der Vordergrundfarbe, ein nicht gesetztes Bit entspricht der Hintergrundfarbe. Bei 
Mustern, die aus mehreren Farbebenen bestehen, wird die volle Anzahl der Ebenen zum Füllen 
benutzt. Nicht aufgeführte Ebenen werden durch Nullebenen ersetzt. “Vielfarbige” Muster 
können nur im Schreibmodus REPLACE eingesetzt werden. 

Deklaration in C: 

void vsf_udpat (WORD handle, WORD *pfillj?at, WORD planes) 

{ 

iioff = pfill_pat; 
contrl[0] = 112; 
contrl[1] ~ 0; 
contrl[3] = planes * 16; 
contrl[6] = handle; 
vdi (); 

iioff = intin; 

} 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

112 

Opcode für VSF_UDPAT 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl [3] 

16*n 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin[0] 

pfill.„pat[0] 

intin+32*n-2 

intin[16*n-l] 

pfill_pat[16*n-l] 
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Parameter: 

planes: Anzahl der Farbebenen 

pfill_pat[0] bis 

pfill_pat[ 15]: Erste Ebene des Füllmusters (Defaultwert ist das Atari- bzw. das DRI-Logo) 

pfill_pat[16] bis 

pfill_pat[31 ]: Zweite Ebene des Füllmusters 


pfill_pat[16*n-16] bis 

pfill_pat[ 16*n-1 ]: (n-te) Ebene des Füllmusters 

Bemerkungen 

Aufgrund eines Tippfehlers in der ursprünglichen Originaldokumentation auch häufig 
“vsf_updatO” genannt. 
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Rasteroperationen 


f COPY RASTER, OPAQUE (VD1109) 


Diese Funktion kopiert (pixelweise) ein rechteckiges Raster unter Beachtung der möglichen 
logischen Verknüpfungen auf ein anderes rechteckiges Raster. Sollten die Größen beider 
Raster nicht übereinstimmen, so wird die Größe des Quellrasters benutzt. Die Adresse des 
Zielrasters dient in diesem Fall lediglich als Zeiger. Ist die Adresse der Quelle und des Ziels 
gleich (und insbesondere ungleich 0 im MFDB), und überlappen die beiden Bereiche, so wird 
das Quellrechteck nicht verändert, solange nicht das Zielrechteck fertig kopiert ist. 

Raster im Standardformat können und dürfen nicht kopiert werden, da man im allgemeinen 
keine Informationen über das gerätespezifische Format hat. Also bei Bedarf vorher “TRANS¬ 
FORM FORM” benutzen! 


Deklaration in C: 

void vro_cpyfm (WORD handle, WORD wr_mode, WORD *pxyarray, 
MFDB *psrcMFDB, MFDB *pdesMFDB) 


intin [0] = wr_mode; 

i_ptr (psrcMFDB); /* contrl[7/8]=psrcMFDB */ 

i_j>tr2 (pdesMFDB); /* contrl[9/10]=pdesMFDP */ 

pioff = pxyarray; 

contrl[0] = 109; 

contrl[1] = 4; 

contrl[3] = 1; 

contrl[6] = handle; 

vdi () ; 

pioff = ptsin; 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

109 

Opcode für VRO_CPYFM 

contrl+2 

contrl[l] 

4 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

1 

# Einträge in intin 
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Adresse 

Feldelemente 

Belegung 

contrl+8 

contrl+12 

contrI+14 

contrl+18 

contrl[4] 

contrl[6] 

contrl[7/8] 

contrl[9/10] 

0 # Einträge in intout 

handle Gerätekennung 
psrcMDFB 
pdesMFDB 

intin 

intin[0] 

wr_mode 

ptsin 

ptsin[0..7] 

pxyarray[0..7] 


Parameter: 

psrcMFDB: 

pdesMFDB: 

wr_mode: 

pxyarray[0]: 

pxyarrayfl]: 

pxyarray[2]: 

pxyarray[3]: 

pxyarray[4]: 

pxyarray[5]: 

pxyarray[6]: 

pxyarray[7]: 


Zeiger auf MFDB des Quellrasters 
Zeiger auf MFDB des Zielrasters 

Eine der 16 möglichen logischen Verknüpfungen (nicht zu verwechseln mit den 
Schreibmodi!) 

X-Koordinate des Eckpunktes des Quellrasters in NDC/RC-Koordinaten 
Y-Koordinate des Eckpunktes des Quellrasters in NDC/RC-Koordinaten 
X-Koordinate der diagonal gegenüberliegenden Ecke des Quellrasters in NDC/ 
RC-Koordinaten 

Y-Koordinate der diagonal gegenüberliegenden Ecke des Quellrasters in NDC/ 
RC-Koordinaten 

X-Koordinate des Eckpunktes des Zielrasters in NDC/RC-Koordinaten 
Y-Koordinate des Eckpunktes des Zielrasters in NDC/RC-Koordinaten 
X-Koordinate der diagonal gegenüberliegenden Ecke des Zielrasters in NDC/ 
RC-Koordinaten 

Y-Koordinate der diagonal gegenüberliegenden Ecke des Zielrasters in NDC/ 
RC-Koordinaten 


Bemerkungen: 

Ein MFDB hat folgende Struktur: 

typedef struct 
{ 

void *fd__addr; /* Zeiger auf Speicherblock. Bei Übergabe 

eines Nullzeigers werden automatisch 
die Parameter für das physikalische Ge¬ 
rät (z.B. Bildschirmspeicher im geräte¬ 
spezifischen Format) gesetzt. */ 

WORD fd_w; /* Speicherblockbreite in Punkten */ 
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WORD fd_h; 

WORD fd_wdwidth; 
WORD fd_stand; 

WORD fd_nplanes; 
WORD fd_rl,fd_r2, 
} MFDB; 


/* Höhe des Speicherblocks in Punkten */ 
/* Breite des Speicherblocks in Words */ 
/* 0: geräteabhängiges Format, 

1: Standardformat */ 

/* Anzahl der Bildebenen */ 
fd r3; /* reserviert */ 


Um es noch einmal ausdrücklich hervorzuheben: Um den Bildschirm anzusprechen, muß ein 
Nullzeiger bei der Speicherblockadresse (und nicht einer irgendwie ermittelten Adresse) ein¬ 
getragen werden. Die Parameter für den Bildschirm werden (intern) automatisch eingetragen, 
was jedoch nicht bedeutet, daß man nach einem Aufruf einer Rasterkopierfunktion die kor¬ 
rekten Werte in der MFDB-Struktur zurückerhält. Bei dem Nullzeiger ist darauf zu achten, 
daß es sich wirklich um einen Nullzeiger und nicht etwa um NIL (= -1), wie bei einigen Modu- 
la-2-Bibliotheken, handelt. 

Die logischen Verknüpfungen (Q = Pixel wert des Quellpixels, Z - Pixelwert des Zielpixels, 
E = Pixelwert des Zielpixels nach Verknüpfung): 


Bezeichnung 


ALLJWHITE (0) 
S_AND_D (1) 
S_AND_NOTD (2) 
S_ONLY (3) 
NOTS_AND_D (4) 
DjDNLY (5) 
S_XOR_D (6) 
S_OR_D (7) 
NOT_SORD (8) 
NOT_SXORD (9) 
D_INVERT (10) 
NOT_D (11) 
S_OR_NOTD (12) 
NOTS_OR_D (13) 
NOT_SANDD (14) 
ALL_BLACK (15) 


Wirkung 


E=0 

E=Q and Z 
E=Q and (not Z) 
E=Q 

E=(not Q) and Z 
E-Z 

E=Q xor Z 
E-Q or Z 
E=not (Q or Z) 
E=not (Q xor Z) 
E=notZ 
E=Q or (not Z) 
E=not Q 
E=(not Q) or Z) 
E=not (Q and Z) 
E=1 
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COPY RASTER, TRANSPARENT (VDI121) 


Diese Funktion kopiert (pixelweise) ein monochromes, rechteckiges Raster unter Beachtung 
der Schreibmodi auf ein anderes (auch farbiges) rechteckiges Raster. Sollten die Größen 
beider Raster nicht übereinstimmen, so werden die Größe des Quellrasters und die obere linke 
Ecke des Zielrasters als Startpunkt benutzt. Als Quellraster darf niemals der Bildschirm 
angegeben werden. 

Die Schreibmodi: 

Modus 1: REPLACE 

Ersetzt alle Pixel des Zielrechtecks, wobei der Vordergrundfarbindex allen Pixeln zugeordnet 
wird, in deren zugehörigem Quellraster eine 1 steht, und der Hintergrundfarbindex allen Pi¬ 
xeln zugeordnet wird, in deren Quellraster eine 0 steht. 

Modus 2: TRANSPARENT 

Hier werden alle Pixel des Zielrechtecks auf die Vordergrundfarbe gesetzt, bei denen im 
zugehörigen Quellraster eine 1 steht. Der Farbindex für die Hintergrundfarbe wird nicht 
benutzt. 

Modus 3: XOR 

Jede Farbebene wird logisch mit dem monochromen Quellraster X-oderiert, d. h. jedes Bit des 
Pixel werts wird ebenenweise mit dem Wert des Quellrasters XORed. Damit ist insbesondere 
die Farbe, die sich aus dieser logischen Operation ergibt, nicht eindeutig definiert. Lediglich 
daß aus Weiß (alle Bits auf 0 gesetzt) Schwarz (alle Bits auf 1 gesetzt) wird (und umgekehrt), 
ist gewiß. Farbindizes werden nicht berücksichtigt. 

Modus 4: REVERSE TRANSPARENT 

Hier werden alle Pixel des Zielrechtecks auf die Hintergrundfarbe gesetzt, bei denen im 
zugehörigen Quellraster eine 0 steht. Der Farbindex für die Vordergrundfarbe wird nicht 
benutzt. 


Deklaration in C: 

void vrt__cpyfm (WORD handle, WORD wr_mode, WORD *pxyarray, 

MFDB *psrcMFDB, MFDB *pdesMFDB, WORD *color__index) 

{ 

intin[0] = wr_mode; 
intin[l] = *colorJ.ndex++; 
intin[2] = *color index; 
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i__ptr (psrcMFDB); /* contrl[7/8]=psrcMFDB */ 

i_ptr2 (pdesMFDB); /* contrl[9/10]=pdesMFDB */ 

pioff = pxyarray; 

contrl[0] = 121; 

contrl[1] = 4; 

contrl[3] = 3; 

contrl[6] = handle; 

vdi (); 

pioff = ptsin; 


GEM-Arrays; 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

121 Opcode für VRT_CPYFM 

contrl+2 

contrl[l] 

4 # Einträge in ptsin 

contrl+4 

contrl[2] 

0 # Einträge in ptsout 

contrl+6 

contrl [3] 

3 # Einträge in intin 

contrl+8 

contrl(4] 

0 # Einträge in intout 

contrl+12 

contrl [6] 

handle Gerätekennung 

contrl+14 

contrl[7/8] 

psrcMFDB 

contrl+18 

contrl[9/10] 

pdesMFDB 

intin 

intin[0] 

wrjnode 

intin+2 

intin[1..2] 

color_index[0.. 1] 

ptsin 

ptsin[0..7] 

pxyarray [0..7] 


Parameter: 

psrcMFDB: 

pdesMFDB: 

wr_mode: 

colorjndex[0]: 

colorJndex[l]: 

pxyarray[0]: 

pxyarray[l]: 

pxyarray [2]: 


Zeiger auf MFDB des Quellrasters 
Zeiger auf MFDB des Zielrasters 
Schreibmodus (siehe oben) 

Farbindex der als gesetzt zu betrachtenden Punkte (Vordergrund) 
Farbindex der als nichtgesetzt zu betrachtenden Punkte (Hintergrund) 
X-Koordinate des Eckpunktes des Quellrasters in NDC/RC-Koordinaten 
Y-Koordinate des Eckpunktes des Quellrasters in NDQRC-Koordinaten 
X-Koordinate der diagonal gegenüberliegenden Ecke des Quellrasters 
in NDC/RC-Koordinaten 
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pxyarray[3]: 

pxyarray[4]: 

pxyarray[5]: 

pxyarray[6]: 

pxyarray[7]: 


Y-Koordinate der diagonal gegenüberliegenden Ecke des Quellrasters in NDC/ 
RC-Koordinaten 

X-Koordinate des Eckpunktes des Zielrasters in NDC/RC-Koordinaten 
Y-Koordinate des Eckpunktes des Zielrasters in NDC/RC-Koordinaten 
X-Koordinate der diagonal gegenüberliegenden Ecke des Zielrasters in NDC/ 
RC-Koordinaten 

Y-Koordinate der diagonal gegenüberliegenden Ecke des Zielrasters in NDC/ 
RC-Koordinaten 
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TRANSFORM FORM (VDI110) 


Diese Funktion transformiert ein Raster vom Standardformat in das gerätespezifische Format 
oder umgekehrt. Beim Standardformathandeltes sich um ein rechnerunabhängiges Datenformat, 
das mithin beim Austausch von Dateien zwischen verschiedenen GEM-Systemen benutzt 
werden kann (siehe COPY RASTER, OPAQUE). 


Die Anzahl der Farbebenen im der Quell-MFDB-Struktur bestimmt die Anzahl der zu 
transformierenden Planes. Das Format-Flag wird für die Ziel-MFDB-Struktur entsprechend 
verändert. Für die korrekte Angabe der restlichen Werte in der Ziel-MFDB-Struktur ist man 
selbst verantwortlich. Je nach geräteabhängigem Format kann der Umwandlungsprozeß ein¬ 
fach oder sehr aufwendig sein. Man erleichtert dem VDI die Arbeit, wenn in Quell- und Ziel- 
MFDB unterschiedliche Rasteradressen angegeben sind - ansonsten kann eine Transforma¬ 
tion schon mal mehrere Minuten dauern (die Umwandlung “in place” ohne Zuhilfenahme von 
temporärem Speicher ist eben eine schwierige Arbeit!). 


Deklaration in C; 

void vr_trnfm (WORD handle, MFDB *psrcMFDB, MFDB *pdesMFDB) 
{ 

i_jptr (psrcMFDB); 
i_ptr2 (pdesMFDB); 
contrl[0] = 110; 
contrl[l] = contrl[3] = 0; 
contrl[6] = handle; 
vdi (); 

1 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

110 

Opcode für VR_TRNFM 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl(2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

contrl+14 

contrl[7/8] 

psrcMFDB 

contrl+18 

contrl[9/10] 

pdesMFDB 
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Parameter: 

psrcMFDB: Zeiger auf MFDB des Quellrasters 
pdesMFDB: Zeiger auf MFDB des Zielrasters 
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GET PIXEL (VDI105) 


Diese Funktion ermittelt den Pixelwert und den Farbindex eines Pixels, 


Der Farbindex ist die Farbnummer, wieman sie gegenüber dem VDI bei den Attributfunktionen 
angeben kann (zum Beispiel bei “vst_color()”). Der Pixelwert hingegen spiegelt den tatsäch¬ 
lichen Inhalt des Bildspeichers wider. 


Deklaration in C: 

void v_get_pixel (WORD handle, WORD x, WORD y, WORD *pel, 
WORD *Index) 

1 

ptsin[0] = x; 
ptsin[l] = y; 
contrl[0] = 105; 
contrl[l] = 1; 
contrl[3] = 0; 
contrl[6] = handle; 
vdi (); 

*pel = intout[0]; 

*index = intout[1J; 

} 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

105 Opcode für V_GET_PIXEL 

contrl+2 

contrl[l] 

1 # Einträge in ptsin 

contrl+4 

contrl [2] 

0 # Einträge in ptsout 

contrl+6 

contrl[3] 

0 # Einträge in intin 

contrl+8 

contrl[4] 

2 # Einträge in intout 

contrl+12 

contrl[6] 

handle Gerätekennung 

ptsin 

ptsin[0] 

X 

ptsin+2 

ptsin[l] 

y 

intout 

intout[0] 

pel 

intout+2 

intout[l] 

index 





424 


ATARI Profibuch 


Parameter: 

x,y: Koordinaten des Pixels 

pel: Pixel wert 

index: Farbindex des Pixels 
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Eingabefunktionen 


I SET INPUT MODE (VDI 33) 

, 


Diese Funktion setzt den Input-Modus auf REQUEST oder SAMPLE. Im REQUEST-Modus 
wartet das Eingabegerät auf eine Eingabe, im SAMPLE-Modus wird lediglich der Zustand 
oder die Position der Eingabeeinheit zurückgegeben. 

Die Eingabefunktionen des VDI funktionieren nur auf der physikalischen Workstation, die im 
Normalfall von den AES benutzt wird. 


Deklaration in C: 


WORD vsinjnode (WORD handle, WORD dev_type, WORD mode) 

{ 

intin[0] = dev_type; 
intin[l] = mode; 
contrlfO] = 33; 
contrl[l] = 0; 
contrl[3] = 2; 
contrl[6] “handle; 
vdi (); 

return intout[0]; /* Vorsicht! Nicht alle Bindings liefern 

einen Return-Wert */ 


} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrlfO] 

33 

Opcode für VSIN.MODE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

2 

# Einträge in intin 

contrl+8 

contrl[4] 

1 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin[0] 

dev_type 

intin+2 

intin[l] 

mode 


intout 

intout[0] 

| Return-Wert 
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Parameter: 

handle: Nummer der physikalischen Workstation 

dev_type: logische Eingabeeinheit 

DEV_LOCATOR (1): Positionseingabeeinheiten (Maus, Trackball, Joy¬ 

stick) 

DEVJVALUATOR (2): Weltverändernde Eingabeeinheiten (Potentiome¬ 

ter, Cursor, im ROM-Treiber nicht implementiert) 
DEV_CHOICE (3): auswählende Eingabeeinheiten (Funktionstasten) 

DEV_STRING (4): Zeichenketteneingabeeinheiten (Tastatur) 

mode: Eingabemodus MODEJREQUEST (1), MODE_S AMPLE (2) 

vsin_mode(): ausgewählter Eingabemodus 

Bemerkungen 

Man beachte, daß es für “INPUT LOCATOR”, “INPUT VALUATOR”, “INPUT CHOICE” 
und “INPUT STRING” für die beiden verschiedenen Eingabemodi zwar unterschiedliche 
Bindings und Funktionsnamen gibt, die Opcodes jedoch jeweils identisch sind! 
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INPUT LOCATOR, REQUEST MODE (VDI28) 

Mit dieser Funktion wird die Position des Grafikcursors gesetzt bzw. ermittelt. Das Ergebnis 
erhält der Benutzer allerdings erst, wenn eine Taste gedrückt wird. Der Grafikcursor wird auf 
jeden Fall an der angegebenen Position in der aktuellen Form auf dem Bildschirm sichtbar. 
Zu beachten ist unbedingt, daß jede beliebige Taste (auch Maustaste) gedrückt werden darf. 

Üblich ist eine Bewegung des Grafikcursors in großen Schritten, wenn die Cursortasten 
gedrückt werden, bzw. in kleinen Schritten, wenn die Cursortasten in Verbindung mit <Shift> 
gedrückt werden. Auf dem Atari benötigt man jedoch zusätzlich die Altemate-Taste. Diese 
Funktion wird nicht von allen Gerätetreibern unterstützt. 

Die Eingabefunktionen des VDI funktionieren nur auf der physikalischen Workstation, die im 
Normalfall von den AES benutzt wird. 

Deklaration in C: 

void vrqALocator (WORD handle, WORD x, WORD y, 

WORD *xout, WORD *yout, WORD *term) 

{ 

ptsin[0] = x; 
ptsin[l] = y; 
contrl[0] = 28; 
contrl[l] = 1; 
contrl[3] = 0; 
contrl[6] -handle; 
vdi (); 

*xout = ptsout[0]; 

*yout = ptsout[l); 

*temn = intout[0]; 

} 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

28 

Opcode für VRQ_LOCATOR 

contrl+2 

contrl [1] 

1 

# Einträge in ptsin 

contrl+4 

contrl [2] 

1 

# Einträge in ptsout 

contrl+6 

contrl(3] 

0 

# Einträge in intin 
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Adresse 

Feldelement 

Belegung 

contrl+8 

contrl[4] 

1 # Einträge in intout 

contrl+12 

contrl[6) 

handle Gerätekennung 

ptsin 

ptsinfO] 

X 

ptsin+2 

ptsin[l] 

y 

intout 

intout[0] 

term 

ptsout 

ptsout[0] 

xout 

ptsout+2 

ptsout[l] 

yout 


Parameter: 

handle: Nummer der physikalischen Workstation 

x: X-Koordinate des Grafikcursors in NDC/RC-Koordinaten 

y: Y-Koordinate des Grafikcursors in NDC/RC-Koordinaten 

term: Im Low-By te wird der Code der (Positions-) Abbruch-Taste eingetragen. Für die 

üblichen Tastaturtasten ist dies der ASCII-Code. Spezielle Tasten am Eingabegerät 
(also die Maustasten) erhalten Werte ab 32 aufwärts und können so nicht ohne 
weiteres von Tasten auf der Tastatur unterschieden werden, 
xout: X-Koordinate des Grafikcursors bei Rückgabe in NDC/RC-Koordinaten 

yout: Y-Koordinate des Grafikcursors bei Rückgabe in NDC/RC-Koordinaten 
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INPUT LOCATOR, SAMPLE MODE (VDI28) 

Mitdieser Funktion wird diePosition des Grafikcursors gesetzt bzw. ermittelt. DerGrafikcursor 
wird nicht sichtbar. Um ihn sichtbar zu machen, muß SHOW CURSOR aufgerufen werden. 
Tastenbetätigungen oder Grafikcursorbewegungen werden nur dann gemeldet, wenn diese 
tatsächlich erfolgt sind. 

Diese Funktion wird nicht von allen Gerätetreibern unterstützt. 

Die Eingabefunktionen des VDI funktionieren nur auf der physikalischen Workstation, die im 
Normalfall von den AES benutzt wird. 

Deklaration in C: 

WORD vsm_locator (WORD handle, WORD x, WORD y, 

WORD *xout, WORD *yout, WORD *term) 

1 

ptsin[0] = x; 
ptsinfl] = y; 
contrl[0] = 28; 
contrl[l] = 1; 
contrl[3] = 0; 
contrl[6] = handle; 
vdi (); 

*xout = ptsout[0]; 

*yout = ptsout[ 1 ]; 

*term = intout[0j; 

return (contrl [4] «1) |contrl[2]; 

1 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

28 

Opcode für VSMJLOCATOR 

contrl+2 

contrl [1] 

1 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 oder 1 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

0 oder 1 

# Einträge in intout 

contrl+12 

contrl[6J 

handle 

Gerätekennung 





430 


ATARI Profibuch 


Adresse 

Feldelement 

Belegung 

ptsin 

ptsin[0] 

X 

ptsin+2 

ptsin[l] 

y 

intout 

intout[0] 

term 

ptsout 

ptsoutfO] 

xout 

ptsout+2 

ptsoutfl] 

yout 


Parameter: 

handle: Nummer der physikalischen Workstation 

Status: Bit 0: Koordinaten verändert? 

Bit 1: Taste gedrückt? 

x: X-Koordinate des Grafikcursors in NDC/RC-Koordinaten 

y: Y-Koordinate des Grafikcursors in NDC/RC-Koordinaten 

term: Im Low-Byte wird der Code der (Positions-) Abbruch-Taste eingegeben. 

Spezielle Tasten am Eingabegerät (also die Maustasten) erhalten Werte ab 32 auf¬ 
wärts und können so nicht ohne weiteres von Tasten auf der Tastatur unterschie¬ 
den werden. 

xout: X-Koordinate des Grafikcursors in NDC/RC-Koordinaten bei Rückgabe 

yout: Y-Koordinate des Grafikcursors in NDC/RC-Koordinaten bei Rückgabe 
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INPUT VALUATOR, REQUEST MODE (VDI 29) 


Mit dieser Funktion wird eine Wertveränderung ermittelt. Es werden immer Werte zwischen 
1 und 100 (nach Tastendruck) zurtickgegeben. Typische Tasten für Wertveränderung sind die 
zwei Cursorbewegungstasten (<T> und <i>). Für die Cursorbewegungstasten erhält man fol¬ 
gende Wertveränderungen (jeweils zum aktuellen Wert): 


Cursorbewegung 

Wert 

<T> 

+ 10 

<i> 

-10 

<t> und <Shift> 

+ 1 

<i> und <Shift> 

- 1 


Diese Funktion wird nicht von allen Gerätetreibern (auch nicht dem im ROM) unterstützt. Die 
Eingabefunktionen des VDI funktionieren nur auf der physikalischen Workstation, die im 
Normalfall von den AES benutzt wird. 


Deklaration in C: 

void vrq_valuator (WORD handle, WORD valuator_in, 

WORD *valuator_out, WORD *terminator) 

{ 

intin[0] = valuator_in; 
contrl[0] = 29; 
contrl[l] = 0; 
contrl[3] = 1; 
contrl[6] = handle; 
vdi (); 

*valuator_out = intouttO); 

*terminator = intout[l]; 

} 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

29 

Opcode für VRQJVALUATOR 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

1 

# Einträge in intin 
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Adresse 

Feldelemente 

Belegung 

contrl+8 

contrl[4] 

2 # Einträge in intout 

contrl+12 

contrl[6] 

handle Gerätekennung 

intin 

intin[0] 

valuator_in 

intout 

intout[0] 

valuator_out 

intout+2 

intout[l] 

terminator 


Parameter: 


handle: 

valuator_in: 

valuator_out: 

terminator: 


Nummer der physikalischen Workstation 
initialisierender Wert 
Ausgabewert 
betätigte Taste 





VDI-Betriebssystemroutinen 


433 


INPUT VALUATOR, SAMPLE MODE (VDI29) 


Mit dieser Funktion wird eine Wertveränderung (ähnlich der Funktion im REQUEST-Modus) 
ermittelt. Es werden Werte zwischen l und 100 zurückgegeben, falls ein entsprechendes 
Ereignis aufgetreten ist. Sonst wird kein Wert zurückgegeben. 

Diese Funktion wird nicht von allen Gerätetreibern (auch nicht dem im ROM) unterstützt. Die 
Eingabefunktionen des VDI funktionieren nur auf der physikalischen Workstation, die im 
Normalfall von den AES benutzt wird. 


Deklaration in C: 

void vsm_valuator (WORD handle, WORD val_in, WORD *val_out, 
WORD *term, WORD *status); 

{ 

intin[0] = val_in; 
contrl[0] = 29; 
contrl[l] = 0; 
contrl[3] = 1; 
contrl[6] = handle; 
vdi (); 

*val_out = intout[0]; 

*term = intout[l]; 

*Status = contrl[4]; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

29 

Opcode für VSM_VALUATOR 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl [3] 

1 

# Einträge in intin 

contrl+8 

contrl[4] 

Status 

# Einträge in intout 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

intin 

intin[0] 

val_in 


intout 

intout[0] 

val_out 


intout+2 

intout[l] 

term 
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Parameter: 

handle: Nummer der physikalischen Workstation 

Status: Auswertung 

0: keine Änderung 
1: Wert verändert 
2: Taste betätigt 
val_in: initialisierender Wert 

val_out: Ausgabewert 

term: ggf. betätigte Taste 
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INPUT CHOICE, REQUEST MODE (VDI30) 


Mit dieser Funktion wird die Betätigung einer Auswahltaste (abgewartet und) ermittelt. Als 
Auswahltasten dienen zum Beispiel die Funktionstasten. 

Die Anzahl der Funktionstasten ist geräteabhängig. Sollte eine andere Taste gedrückt werden, 
so wird die Codenummer dieser Taste zuriickgegeben. 

Diese Funktion ist zwar im ROM implementiert, scheint aber in keiner Weise zu funktionieren. 
Da sie nicht unbedingt nötig ist, wird sie von einigen Gerätetreibern nicht unterstützt. 

Die Eingabefunktionen des VDI funktionieren nur auf der physikalischen Workstation, die im 
Normalfall von den AES benutzt wird. 


Deklaration in C: 


void vrc[_choice (WORD handle, 
{ 


} 


intin[0] 
contrl[0] 
contrl(1] 
contrl[3] 
contrl[6] 
vdi (); 
*ch out = 


= ch_in; 

= 30; 

= 0 ; 

= l; 

= handle; 

! intout[0]; 


WORD ch in. 


WORD *ch out) 


GEM-Arrays; 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

30 

Opcode für VRQ_CHOICE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl [3] 

1 

# Einträge in intin 

contrI+8 

contrl[4] 

1 

# Einträge in intout 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

intin 

intinfO] 

ch_in 


intout 

intout[0] 

ch_out 
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Parameter: 

handle: Nummer der physikalischen Workstation 

ch_in: initialisierende Auswahltaste (ausgewählt wird aus dem Zahlenbereich von 1 bis 

a, wobei die Auswahltastenanzahl a geräteabhängig ist, Beispiel: a = 10, zehn 
(Funktions- oder) Auswahltasten) 
ausgewählte Taste (oder Codenummer) 


ch_out: 
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INPUT CHOICE, SAMPLE MODE (VDI30) 


Mit dieser Funktion wird die Nummer der zuletzt betätigten Auswahltaste ermittelt. Als Aus¬ 
wahltasten dienen zum Beispiel die Funktionstasten. 

Die Anzahl der Funktionstasten ist geräteabhängig. Sollte eine andere Taste gedrückt worden 
sein, so wird die Codenummer dieser Taste zurückgegeben. 

Diese Funktion ist zwar im ROM implementiert, scheint jedoch nicht richtig zu funktionieren. 
Ferner ist die Funktion nicht unbedingt nötig und wird daher von einigen Gerätetreibern nicht 
unterstützt. 

Die Eingabefunktionen des VDI funktionieren nur auf der physikalischen Workstation, die im 
Normalfall von den AES benutzt wird. 

Deklaration in C: 

WORD vsm_choice (WORD handle, WORD *choice) 

{ 

contrl[0] = 30; 
contrl[l] = contrl[3] = 0; 
contrl[6] = handle; 
vdi (); 

*choice = intout[0]; 
return contrl[4]; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

30 

Opcode für VSM_CHOICE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

Status 

# Einträge in intout 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

intout 

intoutfO] 

choice 
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Parameter: 

handle: Nummer der physikalischen Workstation 

Status: Auswahlstatus 

0: keine Taste betätigt 
1: Taste betätigt 

choice: betätigte Auswahltaste (oder Code-Nummer) oder 0, falls keine Taste gedrückt 

wurde. 
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INPUT STRING, REQUEST MODE (VDI31) 


Diese Funktion gibt einen String (abgeschlossen mit RETURN oder bei Erreichen des String- 
Endes) von der Tastatur zurück. Ein Echo auf dem Bildschirm kann erfolgen. Im Fall der Echo¬ 
ausgabe werden die Textattribute berücksichtigt. Die Echoausgabe ist nicht auf allen Geräten 
verfügbar. 

Die Eingabefunktionen des VDI funktionieren nur auf der physikalischen Workstation, die im 
Normalfall von den AES benutzt wird. 

Deklaration in C: 

void vrq_string (WORD handle, WORD raax_length, WORD echo_mode, 

WORD *echo_xy, char *string); 

{ 

WORD tmp; 

intin[0] = max_length; 
intin[l] = echo_mode; 
pioff = echo_xy; 
contrl[0] = 31; 
contrl[1] = 1; 
contrl[3] = 2; 
contrl[6] = handle; 
vdi (); 

for (tmp = 0; tmp<contrl[4]; tmp++) 

*string++ = intout[tmp]; 

*string = 0; 
pioff = ptsin; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

31 

Opcode für VRQ.STRING 

contrl+2 

contrI[l] 

1 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl [3] 

2 

# Einträge in intin 

contrl+8 

contrl[4] 

n 

# Einträge in intout 

contrl+12 

contrl [6] 

handle 

Gerätekennung 
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Adresse 

Feldelemente 

Belegung 

intin 

intin [0] 

max_length 

intin+2 

intin[l] 

echo_mode 

ptsin 

ptsin[0..1] 

echo_xyf0..1] 

intout 

intout[0..n-l] 

string[0..n-l] 


Parameter: 


handle: 

max_length: 


echo_mode: 

echo_xy[0]: 

echo_xy[l]: 

String: 


Nummer der physikalischen Workstation 

maximale Länge des Strings. Im Fall einer negativen Zahl wird der Absolut- 
Betrag der Zahl als Länge genommen (hier nicht mit ASCII-Zeichen, sondern 
mit den Codenummern der VDI-Standard-Tastatur, siehe Anhang). 
Echo-Modus (0: aus, 1: Echo ein (also gleichzeitige Textausgabe auf dem 
Monitor)) 

X-Koordinate für Startpunkt Echoausgabe in NDC/RC-Koordinaten 
Y-Koordinate für Startpunkt Echoausgabe in NDC/RC-Koordinaten 
Zeiger auf Eingabepuffer (für ein C-Binding Null-terminiert, die Länge bein¬ 
haltet die 0.) 
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INPUT STRING, SAMPLE MODE (VDI31) 

Diese Funktion gibt einen String von der Tastatur zurück. Die Eingabe wird abgebrochen 
durch 

- RETURN 

- Erreichen der maximalen Eingabelänge 

- nicht verfügbare Datenwerte. 

Soll die Stringeingabe grundsätzlich mitRETURNabgeschlossen werden, so istderREQUEST- 
Modus zu wählen. 

Ein Echo auf dem Bildschirm kann erfolgen, falls für das Gerät verfügbar. Im Fall der Echoaus¬ 
gabe werden die Textattribute berücksichtigt. 

Die Eingabefunktionen des VDI funktionieren nur auf der physikalischen Workstation, die im 
Normalfall von den AES benutzt wird. 


Deklaration in C: 


WORD vsm_string (WORD handle, WORD max_length, WORD echo_mode, 
WORD *echo_xy, char *string) 

{ 

WORD tmp; 


intinfO] = max_length; 
intin[l] = echqjnode; 
pioff = echo_xy; 
contrl[0] = 31; 
contrlfl] - 1; 
contrl[3] = 2; 
contrl[6] = handle; 
vdi (); 

forftmp = 0; tmp<contrl[4]; tmp++) 
*string++ = intout[tmp]; 

*string = 0; 
pioff = ptsin; 
return contrl[4]; 






442 


ATARI Profibuch 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

31 Opcode für VSM_STRING 

contrl+2 

contrlfl] 

1 # Einträge in ptsin 

contrl+4 

contrl[2] 

0 # Einträge in ptsout 

contrl+6 

contrl[3] 

2 # Einträge in intin 

contrl+8 

contrl[4] 

Status # Einträge in intout 

contrl+12 

contrl [6] 

handle Gerätekennung 

intin 

intin[0] 

max_length 

intin+2 

intin[l] 

echo_mode 

ptsin 

ptsin[0.,l] 

echo_xy[0..1] 

intout 

intout[0..n-l] 

string[0..n-l] 


Parameter: 


handle: 

Status: 

max_length: 


echo_mode: 

echo_xy[0]: 

echo_xy[l]: 

string: 


Nummer der physikalischen Workstation 

Eingabe durch ungültige Zeicheneingabe abgebrochen (0) oder Länge des 
Strings (>0) 

maximale Länge des Strings. Im Falle einer negativen Zahl wird der Absolut- 
Betrag der Zahl als Länge genommen (hier nicht mit ASCII-Zeichen, sondern 
mit den Code-Nummern der VDI-Standard-Tastatur (siehe Anhang)). 
Echo-Modus (0: aus, 1: Echo ein (gleichzeitige Ausgabe auf Bildschirm)) 

X-Koordinate für Startpunkt Echoausgabe in NDC/RC-Koordinaten 
Y-Koordinate für Startpunkt Echoausgabe in NDC/RC-Koordinaten 
Zeiger auf eingelesene Zeichenkette (auf ausreichende Länge achten), bei 
einem C-Binding nullterminiert. Die 0 zählt dann mit zur Länge. 



VDI-Betriebssystemroutinen 


443 


SET MOUSE FORM (VDI111) 


Mit dieser Funktion kann die Form des Grafik-Cursors (Mauszeigers) frei definiert werden. 
Die Hintergrund- und Vordergrundmaske werden getrennt definiert. 

Jede Maske wird als Feld mit 16 Wörtern zu je 16 Bit festgelegt. Hierbei ist Bit 15 des ersten 
Wortes die obere linke Ecke der Maske und Bit 0 des 16. Wortes die rechte untere Ecke. 

Für beide Masken wird ebenso die Farbe getrennt angegeben. Als Hintergrundfarbe wird in 
der Regel 0 (weiß), als Vordergrundfarbe 1 (schwarz) gewählt. 

Zusätzlich wird der Hot-Spot, die exakte Grafik-Cursor-Position, definiert. Bei dem Mauspfeil 
würde dies der Zeigerspitze, bei dem Kreuz der Mitte entsprechen. Die Koordinaten werden 
relativ zur oberen linken Ecke der Maske angegeben. 

Die Ausgabe der Maus erfolgt folgendermaßen: 

- Die Bilddaten unter dem Mauszeiger werden gerettet und bei einer Mausbewegung 
wiederhergestellt. 

- Gesetzte Flächen der Hintergrundmaske werden in der Maskenfarbe ausgegeben. 

- Gesetzte Flächen der Vordergrundfarbe werden in der Datenfarbe ausgegeben. 

Die Eingabe-Funktionen des VDI funktionieren nur auf der physikalischen Workstation, die 
im Normalfall von den AES benutzt wird. Statt dessen sollte man “graf_mouse()” einsetzen! 


Deklaration in C: 

void vscjEorm (WORD handle, WORD *pcur_form) 
{ 

iioff = pcur_form; 
contrl[0] = 111; 
contrl[l] = 0; 
contrl[3] = 37; 
contrl[6] = handle; 
vdi (); 

iioff = intin; 


} 
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GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

111 

Opcode für VSC_FORM 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

37 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin[0..36] 

pcur_form[0..36] 


Parameter: 

handle: Nummer der physikalischen Workstation 

pcur_form[0]: (relative) X-Koordinate des Hot-Spot 

pcur_form[ 1 ]: (relative) Y-Koordinate des Hot-Spot 

pcur_form[2]: 1 (für zukünftige Anwendung) 
pcur_form[3]: Farbindex der Hintergrundmaske (üblich: 0) (Maske) 
pcur_form[4]: Farbindex der Vordergrundmaske (üblich: 1) (Daten) 
pcur_form[5] bis 

pcur_form[20]: Hintergrundmasken-Definition 
pcur_form[21j bis 

pcur_form[36]: Vordergrundmasken-Definition 
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Möchte man eine eigene Anwendung mit einem Timerinterrupt aufrufen, so kann er mit dieser 
Funktion auf diese Anwendung gelegt werden. Es ist die Aufgabe der Anwendung, die alte 
Interrupt-Adresse zu speichern und am Ende das Register wiederherzustellen. Die Eingabe- 
Funktionen des VDI funktionieren nur auf der physikalischen Workstation, die im Normalfall 
von den AES benutzt wird. 


Deklaration in C: 


void vex_timv 
{ 


(WORD handle, LONG tim_addr, LONG *otim_addr, 
WORD *tim conv) 


i_ptr (tim_addr); /* contrl [7/8 ]=tiiri__addr */ 

contrl[0] = 118; 

contrl[1] = contrl[3] = 0; 

contrl[6] = handle; 

vdi {); 

m_lptr2 {otim_addr); /* *otim_addr=contrl[9/10] */ 
*tim_conv = intout[0]; 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

118 

Opcode für VEX_TIMV 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contr![3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

1 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

contrl+14 

contrl[7/8] 

tim_addr 

contrl+18 

contrl [9/10] 

otim_addr 

intout 

intout[0] 

tim_conv 


Parameter: 


handle: 

tim_addr: 

otim_addr: 

tim_conv: 


Nummer der physikalischen Workstation 
Adresse der neuen Timerinterruptroutine 
Adresse der alten Timerinterruptroutine 
Interruptintervall in Millisekunden 
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SHOW CURSOR (VD1122) 


Diese Funktion zeigt den Grafik-Cursor, genauer: annulliert einen Aufruf der Hide-Cursor- 
Funktion. Erst mit Erscheinen des Grafik-Cursors auf dem Bildschirm kann dieser mit der 
Maus bewegt werden. 

Zu beachten ist, daß gegebenenfalls für jedes Hide-Cursor-Kommando auch ein Show- 
Cursor-Kommando gegeben werden muß. Es besteht also die Möglichkeit, die Show- und 
Hide-Cursor-Kommandos ineinander zu verschachteln. Auf die saubere Verschachtelung 
muß selbst geachtet werden. Die Eingabe-Funktionen des VDI funktionieren nur auf der 
physikalischen Workstation, die im Normalfall von den AES benutzt wird. Statt dessen sollte 
man “graf_mouse()” benutzen. 

Deklaration in C: 

void v_show_c (WORD handle, WORD reset) 

{ 

intin[0] = reset; 
contrl[0] = 122; 
contrl[l] = 0; 
contrl[3] =1; 
contrl[6] = handle; 
vdi (); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

122 

Opcode für V_SHOW_C 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

eontrl[3] 

1 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin[0] 

reset 



Parameter: 


handle: Nummer der physikalischen Workstation 

reset: Reset-Flag. 0: Anzahl der Hide-Cursor-Aufrufe wird ignoriert (Maus erscheint 

sofort wieder), sonst: normale Funktion (ein Hide-Cursor-Aufruf wird annulliert). 
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HEDE CURSOR (VDI123) 


Diese Funktion bewirkt das Ausschalten des Grafik-Cursors, womit der Benutzer der 
Anwendung keinen Einfluß auf diesen Cursor mehr hat. 

Die Eingabe-Funktionen des VDI funktionieren nur auf der physikalischen Workstation, die 
im Normalfall von den AES benutzt wird. Statt dessen sollte man “graf_mouse()” benutzen. 


Deklaration in C: 

void v_hide_c (WORD handle) 

{ 

contrl[03 = 123; 
contrl[1] = contrl[3] = 0; 
contrl[6] = handle; 
vdi () ; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

123 

Opcode für V_HIDE_C 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] , 

0 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 


Parameter: 

handle: Nummer der physikalischen Workstation 
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SAMPLE MOUSE BUTTON STATE (VDI124) 


Diese Funktion gibt eine Mausinformation, Position des Grafik-Cursors und Status der 
Maustasten, zurück. 

Die Eingabe-Funktionen des VDI funktionieren nur auf der physikalischen Workstation, die 
im Normalfall von den AES benutzt wird. 

Statt dessen sollte man “graf_mkstate()” oder die Event-Funktionen benutzen. 

Deklaration in C: 

void vq_mouse (WORD handle, WORD *pstatus, WORD *x, WORD *y) 

{ 

contrlfO] = 124; 
contrl[1] = 0; 
contrl[3] = 0; 
cont rl[6] = handle; 
vdi (); 

*pstatus = intout[03; 

*x = ptsout[0]; 

*Y = ptsout[1]; 

1 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrlfO] 

124 Opcode für VQ. MOUSE 

contrl+2 

contrlfl] 

0 # Einträge in ptsin 

contrl+4 

contrl[2] 

1 # Einträge in ptsout 

contrl+6 

contrl [3] 

0 # Einträge in intin 

contrl+8 

contrl[4] 

1 # Einträge in intout 

contrl+12 

contrlfö] 

handle Gerätekennung 

intout 

intoutfO] 

pstatus 

ptsout 

ptsoutfO] 

X 

ptsout+2 

ptsoutfl] 

y 
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Parameter: 

handle: Nummer der physikalischen Workstation 

pstatus: Maustastenstatus (Bit 0: linke Taste, Bit 1: Taste rechts daneben, weitere Bits: 

weitere Tasten) 

x: X-Koordinate des Grafik-Cursors in NDC/RC-Koordinaten 

y: Y-Koordinate des Grafik-Cursors in NDC/RC-Koordinaten 
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EXCHANGE BUTTON CHANGE VECTOR (VDI125) 


Diese Funktion erlaubt den Aufruf einer Anwender-Routine durch Maustastendruck. Hierzu 
wird lediglich die Adresse der Maustasten-Status-Routine geändert. Das heißt, die Adresse der 
Routine, die vorher auf Maustastendruck reagierte, wird in eine anwendereigene Adresse 
umgewandelt. 

Es ist die Aufgabe der Anwendung, die alte Maustasten-Status-Adresse zu speichern und am 
Ende das Register wiederherzustellen. 

Die Eingabe-Funktionen des VDI funktionieren nur auf der physikalischen Workstation, die 
im Normalfall von den AES benutzt wird. 


Deklaration in C: 

void vex_butv (WORD handle, LONG pusrcode, LONG *psavcode) 

{ 

i_ptr (pusrcode); /* contrl[7/8]=pusrcode */ 

contrl[0] = 125; 

contrl[1] = contrl[3] = 0; 

contrl[6] = handle; 

vdi (); 

m_lptr2 (psavcode); /* *psavcode=contrl[9/10] */ 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

125 

Op code für VEX_BUTV 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

contrl+14 

contrl[7/8] 

pusrcode 

contrl+18 

contrl[9/10] 

psavcode 


Parameter: 


handle: Nummer der physikalischen Workstation 
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pusrcode: Adresse der neuen Maustasten-Status-Routine. In Register DO erhält die eigene 

Routine den Status der Maustasten, Das VDI bearbeitet DO nach Beendigung 
der Routine weiter - man kann also beispielsweise ein Bit abfragen, bearbeiten 
und löschen und das andere unversehrt lassen, 
psavcode: Adresse der alten Maustasten-Status-Routine 
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Diese Funktion erlaubt den Aufruf einer Anwender-Routine durch Mausbewegung. Hierzu 
wird lediglich die Adresse der Mausbewegungs-Routine geändert. Das heißt, die Adresse der 
Routine, die vorher auf Mausbewegungen reagierte, wird in eine anwendereigene Adresse 
umgewandelt. Die Verzweigung in eine anwendereigene Routine erfolgt nach Änderung der 
Grafik-Cursor-Position, aber vor Aktualisierung der neuen Position auf dem Bildschirm. Es 
ist die Aufgabe der Anwendung, die alte Mausbewegungs-Adresse zu speichern und am Ende 
das Register wiederherzustellen. Die Eingabe-Funktionen des VDI funktionieren nur auf der 
physikalischen Workstation, die im Normalfall von den AES benutzt wird. 

Deklaration in C: 

void vex_motv (WORD handle, LONG pusrcode, LONG *psavcode) 

{ 

ijotr (pusrcode); /* contrl[7/8]=pusrcode */ 

contrl[0] = 126; 

contrl [1] = contrl[3] = 0; 

contrl[6] = handle; 

vdi(); 

m_lptr2 (psavcode); /* *psavcode=contrl[9/10] */ 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

126 

Opcode für VEX_MOTV 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

contrl+14 

contrl[7/8] 

pusrcode 

contrl+18 

contrl[9/10] 

| psavcode 


Parameter; 

handle; Nummer der physikalischen Workstation 

pusrcode: Adresse der neuen Mausbewegungs-Routine (in DO und Dl werden die 

aktuellen Koordinaten der Maus geliefert) 
psavcode; Adresse der alten Mausbewegungs-Routine 
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EXCHANGE CURSOR CHANGE VECTOR (VDI127) 


Diese Funktion erlaubt den Aufruf einer Anwender-Routine durch Grafik-Cursor-Verände¬ 
rung. Hierzu wird lediglich die Adresse der Grafik-Cursor-Zeichenroutine geändert. 

Das beißt, die Adresse, die vorher auf eine Grafik-Cursor-Neuzeichenroutine zeigte, wird in 
eine anwendereigene Adresse umgewandelt. 

Die Verzweigung in eine anwendereigene Routine erfolgt nach Neuzeichnen des Grafik- 
Cursors. Esist die Aufgabe der Anwendung, die Adresse der alten Grafik-Cursor-Zeichenroutine 
zu speichern und am Ende das Register wiederherzustellen. 

Die Eingabe-Funktionen des VDI funktionieren nur auf der physikalischen Workstation, die 
im Normalfall von den AES benutzt wird. 


Deklaration in C: 

void vex_curv (WORD handle, LONG pusrcode, LONG *psavcode) 

{ 

i_ptr (pusrcode); /* contrl[7/8]=pusrcode */ 

contrl[0] = 127; 

contrl[1] = contrl[3] = 0; 

contrl [6] = handle; 

vdi () ; 

m_lptr2 (psavcode); /* *psavcode=contrl[9/10] */ 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

127 

Opcode für VEX„CURV 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+12 

contrlfö] 

handle 

Gerätekennung 

contrl+14 

contrl[7/8] 

pusrcode 

contrl+18 

contrl [9/10] 

psavcode 
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Parameter: 

handle: 

pusrcode: 

psavcode: 


Nummer der physikalischen Workstation 

Adresse der neuen Neuzeichen-Routine (in DO und Dl werden die aktuellen 
Koordinaten der Maus geliefert). Wenn die eigene Routine den Grafik-Cursor 
nicht neuzeichnet, sollte man am Ende in die bisherige Routine weiterverzweigen! 
Adresse der alten Neuzeichen-Routine 
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| SAMPLEKEYBOARDSTATEINFORMATION(VDI128) 


Diese Funktion gibt eine Tastaturinformation, Status der Control-, der Altemate-, der rechten 
und linken Shifttaste, zurück. Die Eingabe-Funktionen des VDI funktionieren nur auf der 
physikalischen Workstation, die im Normalfall von den AES benutzt wird. Statt dessen sollte 
man “graf_mkstate()” oder die Event-Funktionen benutzen. 


Deklaration in C: 

void vq_key_s (WORD handle, WORD *pstatus) 
l 

contrl[0] = 128; 
contrl[l] = contrl[3] = 0; 
contrlfß] = handle; 
vdi (); 

*pstatus = intout [0]; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

128 

Opcode für VQ_KEY_S 

contrl+2 

contrI[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

1 

# Einträge in intout 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

intout 

intout[0] 

pstatus 



Parameter: 


handle: 

pstatus: 


Nummer der physikalischen Workstation 


Tastaturstatus: 
K_RSHIFT (0x0001): 
K_LSHIFT (0x0002): 
K_CTRL (0x0004): 
K_ALT (OxOOOS): 


Bitbelegung: 
rechte Shift-Taste 
linke Shift-Taste 
Control-Taste 
Altemate-Taste 
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Auskunftsfunktionen 



Diese Funktion gibtentweder Auskunft über die mit “ÖPEN WORKSTATION” (“v_opnwk()”) 
eingestellten Parameter oder eine erweiterte Auskunft. Die Beschreibung der Parameter 
bezüglich “OPEN WORKSTATION” ist unter dem entsprechenden Funktionsaufruf zu 
finden. 


Deklaration in C: 

void vq^extnd (WORD handle, WORD owflag, WORD *work_out) 
1 

iioff = intin; 
pioff = ptsin; 
iooff = work_out; 
pooff = &(work_out[45]); 
intin[0]= owflag; 
contrl[0] = 102; 
contrl[1] = 0; 

Contrl[3] = 1; 
contrl[6] = handle; 
vdi () ; 

iioff = intout; 
pioff = ptsout; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

102 

Opcode für VQ_EXTND 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

6 

# Einträge in ptsout 

contrl+6 

contrl[3] 

1 

# Einträge in intin 

contrl+8 

contrl [4] 

45 

# Einträge in intout 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

intin 

intin [0] 

owflag 


intout 

intout[0..44] 

work_out[0..44] 

ptsout 

ptsout[0..11] 

| work_out[45..56] 
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Parameter: 

owflag: 

work_out[0]: 


work_out[l]: 

work_out[2]: 

work_out[3]: 

work_out[4]; 

work_out[5]: 

work_out[6]: 

work_out[7]: 

work_out[8]: 

work_out[9]: 

work_out[10]: 

work_out[U]: 

work_out[12]: 

work_out[13]: 

work_out[14]: 


work_out[15): 

work_out[16]: 

work_out[17]: 

work_out[18]: 
work_out[19]: 
work_out[20] bis 
work_out[44]: 
work_out[45]: 


Informationstyp (0: V_.OPNWK-Parameter, Standardparameter, 1: er¬ 
weiterte Parameter) 

Bildschirmtyp 
0: kein Bildschirm 

1: getrennter Alpha- und Grafikkontroller und getrennte Bildschir¬ 

me 

2: getrennter Alpha- und Grafikkontroller mit gemeinsamem Bild¬ 

schirm 

3: gemeinsamer Alpha- und Grafikkontroller mit getrenntem Bild¬ 

speicher 

4: gemeinsamer Alpha- und Grafikkontroller mit gemeinsamem 

Bildspeicher 

Anzahl der verfügbaren Hintergrundfarben 

Bit-Vektor der verfügbaren Texteffekte (wie bei “vst_effects()”) 

Flag für Vergrößerungsraster (0: Vergrößern nicht möglich, 1: Vergrö¬ 
ßern möglich) 

Anzahl der Farbebenen 

“Lookup-table”-Unterstützung (0: nicht möglich, 1: möglich) 

Anzahl der I6xl6-Pixel-Raster-Operationen pro Sekunde 
CONTOUR-FILL Verfügbarkeit (0: nicht verfügbar, 1: verfügbar) 
Textrotation (0: nicht möglich, 1: 90 Grad-Drehungen, 2: beliebig) 
Anzahl der Schreibmodi 

höchster Grad der Eingabemodi (0: keine, 1: request, 2: sample) 
Textausrichtungsverfügbarkeit (0: nicht verfügbar, 1: verfügbar) 
Farbstiftwechsel am Ausgabegerät (0: nicht möglich, 1: möglich) 
Farbbandwechselmöglichkeit (0: nicht möglich, 1: farbige Zeilen, 2: 
farbige Zeilen und Rechtecke) 

maximale Anzahl von Koordinatenpaaren fürPolyline, Polymarkerund 
Filled Area (-1: unbegrenzt). TOS 3.01 liefert an dieser Stelle einen 
falschen Wert (512 statt 256). Abhilfe: TOS 3.05 einsetzen. 
maximale Größe des INTIN-Arrays (-1: unbegrenzt) 

Anzahl der Maustasten 

Linientypen für breite Linien (über 1 Pixel Breite) (0: nicht möglich, 1: 
möglich) 

Schreibmodi für breite Linien (0: nicht verfügbar, 1: verfügbar) 
Clipping aus (0) oder an (1). Nur auf PC-GEM ab Version 2.0! 

reserviert, enthält 0 als Ausgabewert. 

obere linke X-Koordinate des Clipping-Rechtecks in NDC/RC-Koor- 
dinaten 
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work_out[46]: 

work_out[47]: 

work_out[48]: 

work_out[49] bis 
work_out[56]: 


obere linke Y-Koordinate des Clipping-Rechtecks in NDC/RC-Koordi- 
naten 

untere linke X-Koordinate des Clipping-Rechtecks in NDC/RC-Koor- 
dinaten 

untere linke Y-Koordinate des Clipping-Rechtecks in NDC/RC-Koor- 
dinaten 

reserviert, enthält 0 als Ausgabewert. 


Bemerkungen 

Zusätzliche Funktion für Matrixdrucker: Es kann die maximale Auflösung angegeben wer¬ 
den: 


ptsin[0]: 

ptsin[l]: 

contrl[l] 


maximale X-Auflösung 
maximale Y-Auflösung 
auf 1 setzen 
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Diese Funktion gibt über die eingestellten Farbintensitäten der Farbpalette Auskunft. Es 
besteht die Möglichkeit, die eingestellte oder die tatsächliche Intensitätsverteilung zu 
erfragen. 


Deklaration in C: 

WORD vg_color (WORD handle, WORD color_index, WORD set_flag, 
WORD *rgb) 

{ 

intin[0] = color_index; 
intin[l] = set_flag; 
contrl[0] =-.26; 
contrlfl] = 0; 
contrl(3] = 2; 
contrl[6] = handle; 
vdi (); 

rgb[0] = intout[1]; 
rgb[1] = intout[2]; 
rgb[2] = intout [3]; 
return intout[0]; 

1 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

26 Opcode für VQ_COLOR 

contrl+2 

contrl[l] 

0 # Einträge in ptsin 

contrl+4 

contrl[2] 

0 # Einträge in ptsout 

contrl+6 

contrl[3] 

2 # Einträge in intin 

contrl+8 

contrl[4] 

4 # Einträge in intout 

contrl+12 

contrl[6] 

handle Gerätekennung 

intin 

intin [0] 

colorjndex 

intin+2 

intin[l] 

set_flag 

intout 

intout[0] 

Return-Wert 

intout+2 

intout[l.,3] 

rgb[0..2] 
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Parameter: 


color_index: 

set_flag: 


rgb[0]: 

rgb[l]: 

rgb[2]: 

vq_color(): 


Farbregister, über das Auskunft erwünscht ist 
Flag für gesetzte oder tatsächliche Farbintensität 
0: gesetzte Intensität 

I: tatsächliche Intensität 

Rotintensität (in Promille, 01000) 

Grünintensität (in Promille, 0-1000) 

Blauintensität (in Promille, 0-1000) 

1, (gewünschter/gesetzter) Farbindex außerhalb der Grenzen 


Bemerkungen 

Gesetzte und tatsächliche Intensität können unterschiedlich sein. Die Intensitäten werden in 
Weiten von 0 bis 1000 angegeben. Verfügt etwa ein Monitor nur über zwei Intensitäten, so 
teilt sich der Bereich in die Teilbereiche Obis 500 und 501 bis 1000. Die tatsächliche Intensität 
kann aber nur 0 oder 1000 sein. Egal welche Zahl man aus dem Bereich 0 bis 500 wählt, immer 
wird die Intensität 0 gesetzt. Also kann beispielsweise die gesetzte Intensität den Wert 47 und 
die tatsächliche den Wert 0 haben. 
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Diese Funktion gibt über die aktuellen gesetzten Linienattribute Auskunft. 


Deklaration in C: 

void vql_attributes (WORD handle, WORD *attrib) 

i 

iooff = attrib; 
contrl[0] = 35; 
contrl[l] = contrl[3] = 0; 
contrl[6] = handle; 
vdi {); 

iooff ~ intout; 
attrib(3] = ptsout[0]; 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

35 

Opcode für VQL_ ATTRIB UTES 

contrl+2 

contrlfl] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

1 

# Einträge in ptsout 

contrl+6 

contrl [3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

3 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intout 

intout[0..2] 

attrib[0..2] 

ptsout 

ptsout[0] 

attrib[5] 

ptsout+2 

ptsout[l] 

0 



Parameter: 


attrib[0]: 
attribfl]: 
attrib[2]: 
attrib[3]: 


Linientyp 

Linienfarbindex 

Schreibmodus 

Linienbreite (bzgl. X-Achse in NDC/RC-Koordinaten) 





462 


ATARI Profibuch 


Bemerkungen 

Die hier gemachten Angaben gelten nur für die im ROM implementierte Funktion. Auch die 
gebräuchlichen Bindings gehen davon aus, obwohl die Beschreibung der Funktion vql_attributes 
in den Anleitungen manchmal etwas anderes behauptet. Nach Digital Research ist die Funk¬ 
tion jedoch ein bißchen anders implementiert (in Übereinstimmung beispielsweise mit den 
GDOS-Druckertreibem). 

Demnach erhält man in intout[0] den Linientyp, in intout[ 1 ] den Linienfarbindex, in intout[2] 
den Schreibmodus, in intout[3] den Linien-Anfangsstil, in intout[4] den Linien-Endstil und 
in ptsout[0j die Liniendicke zurück. Man beachte daher nach Rückkehr vom Funktionsaufruf 
contrl[4]! 
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I INQLIRE CURRENT POLYMARKER ATTRIBUTES (VDI36) 

Diese Funktion gibt über die aktuellen gesetzten Markerattribute Auskunft. 


Deklaration in C: 

void vqm_ attributes (WORD handle, WORD *attrib) 
{ 

iooff = attrib; 
contrl[0] = 36; 
contrl[l] = contrl[3] = 0; 
contrl[6] = handle; 
vdi (); 

iooff = intout; 
attrib[3] = ptsout[1]; 


GEM-Arrays; 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

36 

Opcode für VQM_ATTRIBUTES 

contrl+2 

contrl f 1] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

1 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

3 

# Einträge in intout 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

intout 

intout[0..2] ; 

attrib[0..2J 

ptsout 

ptsout[0] 

0 


ptsout+2 

ptsout[ 11 

attrib[3] 


Parameter: 


attrib[0] 

attrib[l] 

attrib[2] 

attrib[3] 


Markertyp 

Markerfarbindex 

Schreibmodus 

Markerhöhe (bzgl. der Y-Achse in NDC/RC-Koordinaten) 
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Bemerkungen 

Die hier gemachten Angaben gelten nur für die im ROM implementierte Funktion. Auch die 
gebräuchlichen Bindings gehen davon aus. Nach Digital Research ist die Funktion jedoch ein 
bißchen anders implementiert (in Übereinstimmung beispielsweise mit den GDOS-Drucker- 
treibem). 

Demnach erhält man in intout[0] den Markertyp, in intout[l] den Markerfarbindex, in 
intout [2] den Schreibmodus, in ptsout[0] die Markerbreite (bzgi. der X-Achse) und in ptsout[ 1 ] 
die Markerhöhe zurück. Man beachte daher bei Rückkehr vom Funktionsaufruf auf ptsout[0], 
ob dort ein Wert ungleich 0 zurückgegeben wurde! 

Es existieren Bindings, bei denen attrib[3] den Wert 0 hat und in attrib[4] die Markerhöhe 
zurückgeliefert wird! 
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INQUIRE CURRENT FILL AREA ATTRIBUTES (VDI37) 


Diese Funktion gibt über die aktuell gesetzten Füllattribute Auskunft. 


Deklaration in C: 

void vqf_attributes (WORD handle, WORD *attrib) 
1 

iooff = attrib; 

contrl[0] = 37; 

contrl[1) = contrl[3] = 0; 

contrl[6] = handle; 

vdi (); 

iooff = intout; 

1 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

37 

Opcode für VQF_ATTRIBUTES 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

5 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intout 

intout[0..4] 

attrib[0..4] 


Parameter: 


attribfO] 

attrib[l] 

attrib[2] 

attrib[3] 

attrib[4] 


Füllmuster (“Fill interior index”) 

Füllfarbindex 

Musterindex (“Fill style index”) 

Schreibmodus 

Umrahmungsstatus (=0: unsichtbar, <>0: sichtbar) 
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INQUIRE CURRENT GRAPHIC TEXT ATTRIBUTES (VDI38) 


Diese Funktion gibt über die aktuellen gesetzten Textattribute Auskunft. 


Deklaration in C: 

void vqt_attributes (WORD handle, WORD *attrib) 

{ 

iooff = attrib; 

pooff = &(attrib[6]); 

contrl[0] = 38; 

contrl [1] = contrl[3] = 0; 

contrl[6] = handle; 

vdi (); 

iooff — intout; 
pooff = ptsout; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

38 

Opcode für V QT_ATTRIBUTES 

contrl+2 

contrlfl] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

2 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

6 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intout 

intout[0..5] 

attrib[0..5] 

ptsout 

ptsout[0..3] 

attrib[6..9] 


Parameter; 

attrib[0]: Zeichensatz 

attribfl]: Textfarbindex 

attrib[2]: Textrotationsrichtung (in 1/10 Grad) 

attrib[3]: horizontale Ausrichtung (0; linksjustiert, 1: zentriert, 2: rechtsjustiert) 

attrib[4]: vertikale Ausrichtung (0: Baseline, 1: Half line, 2: Ascent line, 3: Bottom line, 

4: Descent line, 5: Top line) 
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attrib[5]: Schreibmodus 

attrib[6]: Zeicbenbreite (bzgl. X-Achse in NDC/RC-Koordinaten) 

attrib[7]: Zeichenhöhe (bzgl. Y-Achse in NDC/RC-Koordinaten) 

attrib[8]: Zeichenzellenbreite (bzgl. X-Achse in NDC/RC-Koordinaten) 

attrib[9): Zeichenzellenhöhe (bzgl. Y-Achse in NDC/RC-Koordinaten) 
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Diese Funktion berechnet die Ausmaße eines minimalen Rechteckes, das den übergebenen 
String enthält. Die Koordinaten der vier Eckpunkte werden relativ zu einem rechtwinkligen 
Koordinatensystem ausgegeben. 

Der niedrigste Eckpunkt des Textrechteckes liegt auf der X-Achse, der am weitesten links 
liegende Eckpunkt auf der Y-Achse. Die Eckpunkte sind entgegen dem Uhrzeigersinn 
durchnumeriert. Der erste Punkt liegt-wenn derTextnormal waagerechtsteht-inderunteren 
linken Ecke des Textrechteckes. Für die Berechnung der Ausmaße des Textrechteckes werden 
alle gesetzten Attribute berücksichtigt. 


Deklaration in C: 

void vqt_extent (WORD handle, const char *string, WORD *extent) 
{ 

WORD *tmp; 
tmp = intin; 

while (*tmp++ = *string++); 
pooff = extent; 
contrltO] = 116; 
contrl[l] = 0; 

contrl[3] = (int)(tmp-intin)-1); 
contrl[6] = handle; 
vdi () ; 

pooff = ptsout; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

116 

Opcode für VQT_EXTENT 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

4 

# Einträge in ptsout 

contrl+6 

contrl [3] 

n 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin[0..n-l] 

string[0..n-l] 

ptsout 

ptsout[0..7] 

extent[0..7] 
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Parameter: 

String: Zeiger auf die Zeichenkette (bei C-Bindings null terminiert) 

extent[0]: relative X-Koordinate des 1. Punktes des Textrechtecks (bzgl. der X-Achse in 

NDC/RC-Koordinaten) 

extent[l j: relative Y-Koordinate des 1. Punktes des Textrechtecks (bzgl, der Y-Achse in 

NDC/RC-Koordinaten) 

extent[2]: relati ve X-Koordinate des 2. Punktes des Textrechtecks (bzgl, der X-Achse in 

NDC/RC-Koordinaten) 

extent[3]: relative Y-Koordinate des 2. Punktes des Textrechtecks (bzgl. der Y-Achse in 

NDC/RC-Koordinaten) 

extent[4]: relative X-Koordinate des 3. Punktes des Textrechtecks (bzgl. der X-Achse in 

NDC/RC-Koordinaten) 

extent[5]: relative Y-Koordinate des 3. Punktes des Textrechtecks (bzgl. der Y-Achse in 

NDC/RC-Koordinaten) 

extent[6]: relative X-Koordinate des 4. Punktes des Textrechtecks (bzgl. der X-Achse in 

NDC/RC-Koordinaten) 

extent[7]: relative Y-Koordinate des 4, Punktes des Textrechtecks (bzgl. der Y-Achse in 

NDC/RC-Koordinaten) 



Abb. 3.10: Koordinatenpunkte bei vql_attributes 
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Diese Funktion berechnet die horizontalen Ausmaße eines Zeichens des aktuellen Zeichensatzes 
und der Zeichenzelle. Die speziellen Texteffekte und Drehungen werden nicht berücksichtigt. 



Abb. 3.11: Die Zeichenzelle 


Deklaration in C: 

WORD vqt__width (WORD handle, WORD character, WORD *cell_width, 
WORD *left_delta, *right_delta) 

{ 

intin[0] = character; 
contrl[0] = 117; 
contrlfl] = 0; 
contrl[3] = 1; 
contrl[6] = handle; 
vdi (); 
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*cell_width = ptsout[0]; 
*left_delta = ptsout[2]; 
*rightjdelta = ptsout [ 4 ]; 
return intout[0]; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

117 Opcode für VQTJWIDTH 

contrl+2 

contrl[l] 

0 # Einträge in ptsin 

contrl+4 

contrl[2] 

3 # Einträge in ptsout 

contrl+6 

contrl[3] 

l # Einträge in intin 

contrl+8 

contrl[4] 

1 # Einträge in intout 

contrl+12 

contrl[6] 

handle Gerätekennung 

intin 

intin[0] 

character 

intout 

intout[0] 

Return-Wert 

ptsout 

ptsout[0] 

cell_width 

ptsout+2 

ptsout[l] 

0 

ptsout+4 

ptsout[2] 

left_delta 

ptsout+6 

ptsout[3] 

0 

ptsout+8 

ptsout[4] 

right_delta 

ptsout+10 

ptsout[5] 

0 


Parameter: 

character: Zeichennummer 

vqt_width(): ASCII-Weit des nachgefragten Zeichens (-1 bei fehlerhafter Wertübergabe) 
cell_width: Zeichenzellenbreite (bzgl. der X-Achse in NDC/RC-Koordinaten) 

Ieft_delta: Abstand linker Zeichenzellenrand zum 1 inken Zeichenrand (bzgl. der X-Achse 

in NDC/RC-Koordinaten) 

right_delta: Abstand rechter Zeichenzellenrand zum rechten Zeichenrand (bzgl. der Y- 
Achse in NDC/RC-Koordinaten) 

Bemerkungen 

Die Werte in “left_delta” und “right_delta” entsprechen exakt den entsprechenden Positionen 
im “Horizontal Offset Table”. Fehlt diese Tabelle im Zeichensatzkopf (und das ist bei den mei¬ 
sten Zeichensätzen der Fall), erhält man als Ergebnis eine Null. 
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INQUIRE FACE NAME AND INDEX (VDI130) 


Diese Funktion gibt über einen Zeichensatznamen und dessen Indexnummer Auskunft. Sie 
ermöglicht es damit erst, bei anderen Funktionen den Zeichensatz über seine Indexnummer 
anzusprechen. 

Deklaration in C: 

WORD vqt_name (WORD handle, WORD element_num, char *name) 

{ 

WORD tmp; 

intintO] = element_num; 
contrl[0] = 130; 
contrl[1] = 0; 
contrl[3] = 1; 
contrl[6] = handle; 
vdi (); 

for (tmp - 0; tmp<32; tmp++) 

name[tmp] = intout[tmp+1]; 
return intout[0]; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

130 Opcode für VQT_NAME 

contrl+2 

contrl[l] 

0 # Einträge in ptsin 

contrl+4 

contrl[2] 

0 # Einträge in ptsout 

contrl+6 

contrl[3] 

1 # Einträge in intin 

contrl+8 

contrl [4] 

33 # Einträge in intout 

contrl+12 

contrl [6] 

handle Gerätekennung 

intin 

intin[0] 

elemenMium 

intout 

intoutfO] 

Return-Wert 

intout+2 

intout[1..32] 

name[0..31] 
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Parameter: 

element_num: 

vqt_name(): 

name: 


Nummer des Zeichensatzes (1 bis Maximalanzahl der verfügbaren Zei¬ 
chensätze. 

Sie ergibt sich aus der Summe des Rückgabewertes beim Öffnen der Work¬ 
station (work_out[10]) und dem Rückgabewert von “vst_load_fonts()”)) 
Index des Zeichensatzes 

Name des Zeichensatzes als maximal 32 Zeichen lange Zeichenkette (z. B. 
“Swiss 721”). 
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INQUIRE CELL ARRAY (VDI27) 


Diese Funktion gibt Auskunft über die Definition des Cell-Arrays. Zu beachten ist, daß diese 
Funktion nicht auf allen Geräten verfügbar ist. 


Deklaration in C: 

void vq_cellarray (WORD handle, WORD *pxyarray, WORD row_length, 
WORD num_rows, WORD *el_used, WORD *rows_used, 
WORD *status, WORD *colarray) 

{ 

pioff = pxyarray; 
iioff = colarray; 
contrl[0] = 27; 
contrl[l] =2; 
contrl[3] = 0; 
contrl[6J = handle; 
contrl[7] = row_length; 
contrl[8] = num_rows; 
vdi () ; 

*el_used = contrl[9]; 

*rows_used = contrl[10]; 

*Status = contrl[ll]; 
pioff = ptsin; 
iioff = intout; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

27 

Opcode für VQ_CELLARRAY 

contrI+2 

contrl[ 1 ] 

2 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrlf4] 

n 

# Einträge in intout 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

contrl+14 

contrl [7] 

row_length 

contrl+16 

contrl[8] 

num_rows 

contrl+18 

contrl [9] 

eLused 
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Adresse 

Feldelement 

Belegung 

contrl+20 

contrl[10] 

rows„used 

contrl+22 

contrlfll] 

Status 

ptsin 

ptsin[0..3] 

pxyarray[0..3] 

intout 

intout[0..n-l] 

colarray(0..n-l] 


Parameter: 

rowjength: 

num_rows: 

el_used: 

rows_used: 

Status: 

pxyarray[0]: 

pxyarray[l]: 

pxyarray[2]: 

pxyarray[3]: 

colarrayf]: 


Zeilenlänge im Farbindex-Array 
Anzahl der Zeilen im Farbindex-Array 
Spaltenanzahl 

Anzahl der benutzten Spalten im Farbindex-Array 

0: keine Fehler, 1: für einige Pixel konnte der Farbwert nicht bestimmt werden. 
X-Koordinate der oberen linken Ecke des Begrenzungsrechteckes 
Y-Koordinate der oberen linken Ecke des Begrenzungsrechteckes 
X-Koordinate der unteren rechten Ecke des Begrenzungsrechteckes 
Y-Koordinate der unteren rechten Ecke des Begrenzungsrechteckes 
Farbindex-Array, enthält die Farbinformation zeilenweise, -1 falls Farbindex 
für den vorgegebenen Bereich nicht bestimmt werden konnte. 
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INQUIRE INPUT MODE (VDI115) 


Diese Funktion gibt Auskunft über den aktuellen Eingabemodus für das spezifizierte, logische 
Eingabegerät. 


Deklaration in C: 

void vqin_mode (WORD handle, WORD dev_type, WORD *input_mode) 
{ 

intin(0] = devjtype; 
contrl[0] = 115; 
contrl[l] = 0; 
contrl[3] = 1; 
contrl[6] = handle; 
vdi () ; 

*input_inode = intout[0]; 

) 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

115 

Opcode für VQIN_MODE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

eontrl[3] 

1 

# Einträge in intin 

contrl+8 

contrl [4] 

1 

# Einträge in intout 

eontrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin [0] 

dev_type 

intout 

intout[0] 

input_mode 


Parameter: 

handle: Kennung der physikalischen Workstation 

dev_type: logische Eingabeeinheit 

1: Positions-Eingabeeinheiten 
2: wertverändemde Eingabeeinheiten 
3: auswählende Eingabeeinheiten 
4: Zeichenketten-Eingabeeinheiten 
input_mode: Eingabe-Modus (1: REQUEST, 2: SAMPLE) 
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Diese Funktion gibt über den aktuellen Zeichensatz Auskunft. Es wird die gegenwärtige Größe 
ausgegeben. Die aktuellen Texteffekte werden ebenso berücksichtigt. Sollten die Zeichen in 
Kursivschrift dargestellt sein, so wird die Neigung als rechter und linker Offsetwert bedacht. 
Rechter Offsetwert ist der horizontale Abstand der Zeichenposition (linkes Basislinienende) 
zum Lotfußpunkt des Lotes auf die Basislinie durch die obere rechte Ecke. Linker Offsetwert 
ist der Abstand der Zeichenposition zum Lotfußpunkt des Lotes auf die Basislinie durch die 
untere linke Ecke. 



Abb. 3.12: Offsetinformationen über den aktuell eingestellten Zeichensatz 


Deklaration in C: 

void vqt_fontinfo (WORD handle, WORD *minÄDE, WORD *maxADE, 

WORD *distances, WORD *maxwidth, WORD *effects) 

1 

contrl[0] = 131; 
contrl[l] = contrl[3] = 0; 
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contrl[6] = handle; 
vdi (); 

*minADE = intout[0]; 
*maxADE = intout[1]; 
*maxwidth = ptsout[0]; 
distances[0] =ptsout[l], 
distances[1] 
distances[2] 
distances[3] 
distances[4] 
effects[0] 
effects[1] 


= ptsout[3], 
= ptsout[5], 
= ptsout[7] i 
= ptsout[9], 
ptsout [2]; 
ptsout[4]; 
effects[2] =ptsout[6]; 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

131 Opcode für VQT_FONTINFO 

contrl+2 

contrl[I] 

0 # Einträge in ptsin 

contrl+4 

contrl [2] 

5 # Einträge in ptsout 

contrl+6 

contrl [3] 

0 # Einträge in intin 

contrl+8 

contrl[4] 

2 # Einträge in intout 

contrl+I2 

contrl [6] 

handle Gerätekennung 

intout 

intout[0] 

minADE 

intout+2 

intout[l] 

maxADE 

ptsout 

ptsout[0] 

maxwidth 

ptsout+2 

ptsout[l] 

distances[0] 

ptsout+4 

ptsout[2] 

effects[0] 

ptsout+6 

ptsout[3] 

distances[l] 

ptsout+8 

ptsout[4] 

effects[l] 

ptsout+10 

ptsout[5] 

distances[2] 

ptsout+12 

ptsout[6] 

effects [2] 

ptsout+14 

ptsout[7] 

distances[3] 

ptsout+16 

ptsout[8] 

0 

ptsout+18 

ptsout[9] 

distances[4] 
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Parameter: 

minADE: 

minADE: 

maxwidth: 

distances[0]: 

distances[l]: 

distances[2] 

distances[3]: 

distances[4]: 

effects[0]: 

effectsfl]: 

effects[2]: 


niedrigster ASCH-Wert, erstes Zeichen des Zeichensatzes 
höchster ASCII-Wert, letztes Zeichen des Zeichensatzes 
maximale Zeichenzellenbreite ohne Texteffekte 
Abstand Untergrenze Zeichenzelle zu Basislinie (bzgl. Y-Achse) 

Abstand Untergrenze Zeichen (Unterlängen) zur Basislinie (bzgl. Y-Achse) 
Abstand Halblinie (Obergrenze Kleinbuchstaben (wie a, c, e, g,)) zur Basislinie 
(bzgl. Y-Achse) 

Abstand Obergrenze Zeichen zur Basislinie (bzgl. Y-Achse) 

Abstand Obergrenze Zeichenzelle zur Basislinie (bzgl. Y-Achse) 

Betrag, um den die Zeichenbreite bei den aktuell eingestellten Texteffekten 
zunimmt (bzgl. X-Achse) 
linker Offsetwert (bzgl. X-Achse) 
rechter Offsetwert (bzgl. X-Achse) 
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- nur auf PC-GEM ab Version 2.0! 


Fragt für jedes Zeichen eines Strings die X- und Y-Offsets von einem gegebenen Ausrichtungs¬ 
punkt ab. 

Deklaration in C: 

void vqt_justified (WORD handle, WORD x, WORD y, 

const char *string, WORD length, 

WORD word__space, WORD char__space, 

WORD *offsets) 

{ 

WORD i; 

contrl[0] = 132; 
contrl[l] = 2; 
intin[0] = word_space; 
intin[1] = char_space; 
i = 0; 

while (tmp[i] = string[i++]) ; 

contrl[3] = i; 

contrl[6] = handle; 

ptsin[0] = x; 

ptsin[1] = y; 

ptsin[2] = length; 

ptsin[3] ~ 0; 

pooff = offsets; 

vdi (); 

pooff = ptsout; 

} 

GEM-Arrays: 


Adresse 
- 1 

Feldelement 

Belegung 

contrl 

contrl[0] 

132 

Opcode für VQT_JUSTIFIED 

contrl+2 

contrlfl] 

2 

# Einträge in ptsin 

contrl+4 

contrl [2] 

n 

# Einträge in ptsout 

contrl+6 

contrl[3] 

2+n 

# Einträge in intin 
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Adresse 

Feldelement 

Belegung 

contrl+8 

contrl[4] 

0 # Einträge in intout 

contrl+12 

contrl[6] 

handle Gerätekennung 

intin 

intin[0] 

word_space 

intin+2 

intin[l] 

char_space 

intin+4 

intin[2..n+l] 

string[0..n+l] 

ptsin 

ptsin[0] 

X 

ptsin+2 

ptsin[l] 

y 

ptsin+4 

ptsin(2] 

length 

ptsin+6 

ptsin[3] 

0 

ptsout 

ptsout[.„] 

offsetsf...] 


Parameter: 


word_space: 


char_space: 


String: 

x: 

y: 

length: 

offsetsQ: 


Flag für Wortzwischenräume 

0: keine Dehnung der Wortzwischenräume 

nicht 0: Dehnung der Wortzwischenräume 

Flag für Zeichenzwischenräume 

0: keine Dehnung der Zeichenzwischenräume 

nicht 0: Dehnung der Zeichenzwischenräume 

Zeiger auf Zeichenkette 

X-Koordinate des Textausrichtungspunktes 

Y-Koordinate des Textausrichtungspunktes 

Textlänge (in Pixeln) bzgl. der X-Richtung 

jeweils für jedes Zeichen in der Zeichenkette der X- und Y-Offsets (das Array 
ist also genau doppelt so lang wie die Zeichenkette) 


Escapes 


ESCAPE (VDI5) 


Die Escape-Funktionen erlauben dem Anwendungsprogramm, spezielle Fähigkeiten von 
Ausgabegeräten auszunutzen. Das betreffende Ausgabegerät ist jeweils neben bzw. unter dem 
Funktionsnamen angegeben. Der Parameter “handle” ist bei allen Funktionen das Gerätehandle. 
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(VDI5, Escape 1) (Bildschirm) 


Diese Funktion gibt über die Anzahl der mit dem Alpha-Cursor ansprechbaren Zeilen und 
Spalten Auskunft. 


Deklaration in C: 

void vq_chcells (WORD handle, WORD *rows, WORD *columns) 

{ 

contrl[0] =5; 
contrl[l] = contrl[3] = 0; 
contrl[5] = 1; 
contrl[6] = handle; 
vdi (); 

*rows = intout[0]; 

*columns = intouttl]; 

} 


GEM-Arrays: 

Adresse Feldelement 

Belegung 

contrl 

contrl[0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl [3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

2 

# Einträge in intout 

contrl+10 

contrl[5] 

1 

V Q_CHCELLS 

contrl+12 

contrl[6] 

handle Gerätekennung 

intout 

intout[0] 

rows 


intout+2 

intout[l] 

columns 


Parameter: 

rows: Anzahl der adressierbaren Zeilen, -1 falls keine Adressierung möglich 

columns: Anzahl der adressierbaren Spalten, -1 falls keine Adressierung möglich 
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EXIT ALPHA MODE (VDI5, Escape 2) (Bildschirm, Metafde) 


Diese Funktion schaltet den Alpha-Modus aus, sofern Alpha- und Grafikmodus unterschied¬ 
lich sind. Gleichzeitig wird der Grafikbildschirm gelöscht (bei einem Metafile wird ein ent¬ 
sprechender Eintrag vorgenommen). 


Deklaration in C: 


void v_exit_cur 
{ 

contrl[0] = 
contrl[1] = 
contrl[5] = 
contrl[6] = 
vdi. (); 

} 


(WORD handle) 

5; 

contrl[3] = 0; 
2 ; 

handle; 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrlfO] 

5 

Opcode für ESCAPE 

contrl+2 

contrl [1] 

0 

# Einträge in ptsin 

eontrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl [3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrl [5] 

2 

V_EXIT_CUR 

contrl+12 

contrl[6] 

| handle Gerätekennung 


Bemerkungen 

Der Alpha-Modus ist der normale Textmodus ohne Grafik, wie er etwa vom Desktop für die 
Anzeige von Dateien benutzt wird. 



484 


ATARI Profibuch 



ENTER ALPHA MODE (VDI5, Escape 3) (Bildschirm, Metafile) j 


Diese Funktion bewirkt das Verlassen des Grafik-Modus, falls dieser nicht identisch mit dem 
Alpha-Modus ist. Ebenso wird der Alpha-Cursor in die obere linke Zeichenzelle gesetzt und 
der Alpha-Bildschirm gelöscht (bei einem Metafile wird ein entsprechender Eintrag vorge¬ 
nommen). 


Deklaration in C: 

void v_enter_cur (WORD handle) 

t 

l 

contrl[0] - 5 ; 
contrl[l] = contrl[3] = 0; 
contrl[5] = 3; 
contrl[6] = handle; 
vdi (); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[ 1 ] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrl(5] 

3. 

v_enter_cur 

contrl+12 

| contrl[6) 

handle 

Gerätekennung 
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ALPHA CURSOR UP (VDI5, Escape 4) (Büdschirm) 


Diese Funktion bewegt den Alpha-Cursor eine Zeile höher, ohne die horizontale Position zu 
verändern. Sollte sich der Cursor in der oberen Zeile befinden, so passiert nichts. 


Deklaration in C: 

void v__curup (WORD handle) 

{ 

contrl[0] = 5; 
contrl[l] = contrl[3] = 0; 
contrl[5] = 4 ; 
contrl[6] = handle; 
vdi (); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

5 

Opcode für ESCAPE 

contrl+2 , 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

4 

V_CURUP 

contrl+12 

contrl[6] 

handle 

Gerätekennung 





486 


ATARI Profibuch 



Diese Funktion bewegt den Alpha-Cursor eine Zeile tiefer, ohne die horizontale Position zu 
verändern. Sollte sich der Cursor in der untersten Zeile befinden, so passiert nichts. 


Deklaration in C: 

void v_curdown (WORD handle) 

{ 

contrl[0] = contrl[5] = 5; 
contrltl] = contrl[3] = 0; 
contrl[6] - handle; 
vdi (); 

1 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

5 

V_CURDOWN 

contrl+12 

contrl[6] 

handle 

Gerätekennung 
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ALPHA CURSOR RIGHT (VDI5, Escape 6) (Bildschirm) 


Diese Funktion bewegt den Alpha-Cursor eine Spalte nach rechts, ohne die vertikale Position 
zu verändern. Sollte sich der Cursor bereits am rechten Bildschirmrand befinden, so passiert 
nichts. 


Deklaration in C: 

void v_curright (WORD handle) 

{ 

contrl[0] = 5; 

contrl[1] = contrl[3] = 0; 

contrl[5] = 6; 

contrl[6] = handle; 

vdi (); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl [3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

6 

V_CURRIGHT 

contrl+12 

contrl[6] 

handle Gerätekennung 
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ALPHA CURSOR LEFT (VDI 5, Escape 7) (Bildschirm) 

__ 


Diese Funktion bewegt den Alpha-Cursor eine Spalte nach links, ohne die vertikale Position 
zu verändern. Sollte sich der Cursor bereits am linken Rand befinden, so passiert nichts. 


Deklaration in C: 


void v_curleft 

{ 

contrl[0] 
contrl[1] 
contrl[5] 
contrl[6] 
vdi (); 

} 


(WORD handle) 

= 5; 

= contrl[3] = 0; 
= 7; 

= handle; 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl [1] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

7 

V.CURLEFT 

contrl+12 

contrl[6] 

i handle Gerätekennung 
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HOME ALPHA CURSOR (VDI5, Escape 8) (Bildschirm) 


Diese Punktion bewegt den Alpha-Cursor in seine “Heim”-Stellung, normalerweise oben 
links auf dem Bildschirm. 


Deklaration in C: 

void v_curhome 
{ 

contrl[0] 
contrl[1] 
contrl[5] 
contrl[6] 
vdi {); 

} 


(WORD handle) 

= 5? 

= contrl[3] = 0; 
= 8 ; 

= handle; 


GEM-Arrays: 


Adresse 

Feldelement 

| Belegung 

contrl 

contrl[0] 

5 

Opcode für ESCAPE 

contrI+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl [3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+10 

contrl [5] 

8 

V_CURHOME 

contrl+12 

contrl[6] 

handle 

Gerätekennung 
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ERASE TO END OF ALPHA SCREEN 
(VDI5, Escape 9) (Bildschirm) 

Diese Funktion löscht den Bildschirm ab der aktuellen Alpha-Cursor-Position, die hierbei 
nicht verändert wird. 

Deklaration in C: 

void vjseos (WORD handle) 

{ 

contrl[0] = 5; 

contrl[1] = contrl[3] = 0; 

contrl[5] = 9; 

contrl[6] = handle; 

vdi (); 

> 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

5 

Opcode für ESCAPE 

contrl+2 

contrlfl] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

9 

V_EEOS 

contrI+12 

contrl[6] 

handle 

Gerätekennung 
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ERASETO END OF ALPHA TEXT LINE 
(VDI5, Escape 10) (Bildschirm) 


Diese Funktion löscht ab der aktuellen Alpha-Cursor-Position die aktuelle Textzeile, wobei 
die Position des Alpha-Cursors nicht verändert wird. 

Deklaration in C: 

void v_eeol (WORD handle) 

{ 

contrl[0] = 5; 

contrl[1] = contrl[3] = 0; 

contrl[5] = 10; 

contrl[6] = handle; 

vdi () ; 

) 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

10 

VJEEOL 

contrl+12 

contrl[6] 

handle Gerätekennung 
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DIRECT ALPHA CURSOR ADDRESS 
(VDI5, Escape II) (Bildschirm) 

Diese Funktion bewegt den Alpha-Cursor zu einer bestimmten Spalte und Zeile. Sollten 
Adressen oberhalb der Maximalgrenze angegeben werden, so nimmt die Funktion den am 
nächsten liegenden Wert. 

Deklaration in C: 

void v_curaddress (WORD handle, WORD row, WORD column) 

{ 

intin[0] = row; 
intin[1] = column; 
contrlfO] = 5; 
contrl[1] = 0; 
contrl[3] = 2; 
contrl[5] = 11; 
contrl[6] = handle; 
vdi (); 

1 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

2 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

11 

V_CURADDRESS 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin[0] 

row 


intin+2 

intin[l] 

column 



Parameter: 

row: Zeile für Cursor-Position (1 bis Maximalanzahl der Zeilen) 

column: Spalte für Cursor-Position (1 bis Maximalanzahl der Spalten) 





VDl-Betriebssystemroutinen 


493 


OUTPUT CURSOR ADDRESSABLE ALPHA TEXT 
(VDI5, Escape 12) (Bildschirm) 


Diese Funktion veranlaßt die Ausgabe einer Zeichenkette ab der aktuellen Alpha-Cursor- 
Position. Man beachte, daß man hiermit schneller (!) Text ausgeben kann als über das GEM- 
DOS! Der Cursor wird dabei für jedes Zeichen eine Stelle weitergerückt (der Alpha-Modus 
muß logischerweise angeschaltet sein). 


Deklaration in C: 


void v_curtext (WORD handle, const char *string) 

{ 

WORD *tmp; 
tmp = intin; 

while (*tmp++ = *string++); 
contrl[0] = 5; 
contrl[1] = 0; 

contrl[3] = ((int) (tmp-intin)-1); 
contrl[5] = 12; 
contrl[6] = handle; 
vdi () ; 

1 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

n 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+10 

contrl [5] 

12 

V_CURTEXT 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

intin 

intin[0..n-l] 

string[0..n-l] 


Parameter: 

String: Zeiger auf die auszugebende Zeichenkette 
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REVERSE VIDEO ON (VDI5, Escape 13) (Bildschirm) 


Mit dieser Funktion wird die inverse Alpha-Textdarstellung eingestellt. 


Deklaration in C: 


(WORD handle) 


void v_rvon 
{ 

contrl[0] 
contrl[1] 
contrl[5] 
contrl[6] 
vdi (); 


5; 

contrl[3] = 0; 
13; 

handle; 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

5 

Opcode für ESCAPE 

eontrl+2 

contrl[I] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

eontrl+10 

contrl [5] 

13 

V_RVON 

contrl+12 

contrl[6] 

handle Gerätekennung 
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REVERSE VIDEO OFF (VDI5, Escape 14) (Bildschirm) 


Mit dieser Funktion wird die inverse Alpha-Textdarstellung abgeschaltet. 


(WORD handle) 
5; 


Deklaration in C: 

void v_rvoff 
{ 

contrl[0] 
contrl[1] 
contrl[5] 
contrl[6] 
vdi () ; 

} 


contrl[3] = 0; 
14; 

handle; 


GEM-Arrays; 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrht4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

14 

VJtVOFF 

contrl+12 

contrl[6] 

handle 

Gerätekennung 
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INQUIRE CURRENT ALPHA CURSOR ADDRESS 
(VDI5, Escape 15) (Bildschirm) 

Diese Funktion gibt über die aktuelle Alpha-Cursor-Position Auskunft. 
Deklaration in C: 

void vq__curaddress (WORD handle, WORD *row, WORD *column) 

{ 

contrl[0] = 5; 
contrltl] = contrl [3] = 0; 
contrl[5] = 15; 
contrl[6] = handle; 
vdi (); 

*row = intout[0]; 

*column = intout[l]; 

} 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

2 

# Einträge in intout 

contrl+10 

contrl[5] 

15 

VQ_CURADDRESS 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intout 

intoutfO] 

row 


intout+2 

intoutfl] 

column 



Parameter: 


row: 

column: 


aktuelle Zeilenposition des Alpha-Cursors 
aktuelle Spaltenposition des Alpha-Cursors 
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INQUIRE TABLET STATUS (VDI5, Escape 16) (Büdschirm) 

Diese Funktion gibt über die Verfügbarkeit eines Grafik-Tabletts, einer Maus, eines Joysticks 
oder eines ähnlichen Gerätes Auskunft. 

Deklaration in C: 

WORD vq_tabstatus (WORD handle) 

{ 

contrl[0] =5; 
contrl[l] = contrl[3] = 0; 
contrl[5] = 16; 
contrl[6) = handle; 
vdi (); 

return 1ntout[0]; 

> 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrI[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

1 

# Einträge in intout 

contrl+10 

contrl[5] 

16 

VQ„TABSTATUS 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intout 

intout[0] 

Retum-Wert 


Parameter; 

vq_tabstatus(): Gerätestatus (0: nicht verfügbar, 1: verfügbar) 
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HARD COPY (VDI5, Escape 17) (Bildschirm) 


Diese Funktion bewirkt die Ausgabe einer Hardcopy auf einen Drucker oder ein entsprechen¬ 
des Gerät. Man beachte, daß dies eine Funktion des Bildschirmtreibers ist (der dazu auf das 
XBIOS zugreift). 

Deklaration in C: 

void vjhardcopy (WORD handle) 

{ 

contrlfO] = 5; 
contrl[l] = contrl[3] = 0; 
contrl[5] = 17; 
contrl[6] = handle; 
vdi (); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

17 

VHARDCOPY 

contrl+12 

contrl[6] 

handle 

Gerätekennung 
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PLACE GRAPHIC CURSOR AT LOCATION 
(VDI5, Escape 18) (Bildschirm) 

Diese Funktion setzt den Grafik-Cursor an eine bestimmte Stelle. Sie ist nur auf Geräten 
verfügbar, die Positionseingaben (Locator) - etwa mit Maus, Joystick oder Trackball - 
zulassen. 


Deklaration in C: 

voicL v_dspcur (WORD handle, WORD x, WORD y) 
{ 

ptsin[0] = x; 
ptsin[1] = y; 
contrl[0] = 5; 
contrl[l] = 1; 
contrl[3] = 0; 
contrl[5] = 18; 
contrl[6] = handle; 
vdi (); 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

5 

Opcode für ESCAPE 

contrl+2 

contrlfl] 

1 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

18 

V_DSPCUR 

contrl- 1-12 

contrl [6] 

handle 

Gerätekennung 

ptsin 

ptsin[0] 

X 


ptsin+2 

ptsin[l] 

y 



Parameter: 

x: X-Koordinate der neuen Grafik-Cursor-Stellung 

y: Y-Koordinate der neuen Grafik-Cursor-Stellung 
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REMOVE LAST GRAPHIC CURSOR 
(VDI5, Escape 19) (Bildschirm) 

Diese Funktion entfernt den zuletzt dargestellten Grafik-Cursor. 

Deklaration in C: 

void v_rmcur (WORD handle) 

{ 

contrl [0] = 5; 

contrl[1] = contrl[3] = 0; 

contrl[5] = 19; 

contrl[6] = handle; 

vdi (); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrlfO] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

19 

VJRMCUR 

contrl+12 

contrl [6] 

handle 

Gerätekennung 
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FORM ADVANCE (VDI5, Escape 20) (Drucker, Metafile) 1 

“FORM ADVANCE” bewirkt einen Seitenvorschub (ähnlich “CLEAR WORKSTATION”). 
Der Datenpuffer wird nicht gelöscht. Falls das “Ausgabegerät” ein Metafile ist, wird ein 
entsprechender Eintrag geschrieben. 

Deklaration in C: 

void v_form_adv (WORD handle) 

{ 

contrl[0] = 5; 
contrl[l] = contrl[3] =0; 
contrl[5] = 20; 
contrl[6] = handle; 
vdi (); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

20 

V_FORM„ADV 

contrl+12 

contrl [6] 

handle 

Gerätekennung 
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OUTPUT WINDOW (VDI5, Escape 21) (Drucker) 


“OUTPUT WINDOW” ist eine Verallgemeinerung von “UPDATE WORKSTATION”, die 
es erlaubt, eine einzige Abbildung auf mehrere Blätter verteilt zu drucken. Einziger 
Unterschied zu “UPDATE WORKSTATION”: Es kann ein Ausschnitt aus dem Drucker- 
Koordinatensystem ausgewählt werden. 

Deklaration in C: 

void v_output_window (handle, WORD *xyarray) 
t 

pioff = xyarray; 
contrl[0] = 5; 
contrl[l] = 2; 
contrl[3] = 0; 
contrl[5] = 21; 
contrl[6] = handle; 
vdi (); 

pioff = ptsin; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

2 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl [3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

21 

V_OUTPUT_WINDOW 

contrl+12 

contrI[6] 

handle Gerätekennung 

ptsin 

ptsin[0..3] 

xyarray[0.,3] 


Parameter; 


xyarray [0]; 
xyarray[l] 
xyarray[2] 
xyarray[3] 


X-Koordinate einer Ecke des Ausgaberechteckes 
Y-Koordinate einer Ecke des Ausgaberechteckes 

X-Koordinate der diagonal gegenüberliegenden Ecke des Ausgaberechteckes 
Y-Koordinate der diagonal gegenüberliegenden Ecke des Ausgaberechteckes 
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CLEAR DISPLAY LIST (VDI5, Escape 22) (Drucker, Metafile) 


Mit “CLEAR DISPLAY LIST” kann der Druckerpuffer (ähnlich “CLEAR WORKSTATION”) 
gelöscht werden. Ein Seitenvorschub wird nicht durchgeführt. 


Deklaration in C: 

void v_clear_disp_list (WORD handle) 
{ 

contrltO] = 5; 

contrl[1] = contrl[3] = 0; 

contrl[5] = 22; 

contrl[6] = handle; 

vdi (); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrl [5] 

22 

V_CLEAR_DISPJLIST 

contrl+12 

contrl[6] 

handle Gerätekennung 
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OUTPUT BIT IMAGE FILE (VDI5, Escape 23) (Drucker, Metafile) 


Mit “OUTPUT BIT IMAGE FILE” kann die in einer IMG-Datei gespeicherte Bild-Informa¬ 
tion gelesen und auf dem Ausgabegerät ausgegeben werden. 


Deklaration in C: 

vcid v_bit_image (WORD handle, const char *filename, WORD aspect, 
WORD x_scale, WORD y_scale, WORD h_align, 

WORD v__align, WORD *xyarray) 

{ 

WORD tmp; 

pioff = xyarray; 
intin[0] = aspect; 
intin [1] = x_scale; 
intin[2] = y_scale; 
intin[3] = h_align; 
intin[4] - v_align; 
tmp = 4; 

while (intin[tmp+t] - *filename++); 

contrl[0] = 5; 

contrl[1] = 2 ; 

contrl[3] = -tmp; 

contrl[5] = 23; 

contrl[6] = handle; 

vdi (); 

pioff = ptsin; 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0J 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

2 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

n+5 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 
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Adresse Feldelement Belegung 

contrl+10 contrl[5] 23 V_BH_IMAGE 

contrl+12 contrl[6] handle Gerätekennung 

intin intin[0] aspect 

intin+2 intinfl] x_scale 

intin+4 intin[2] y_scale 

intin+6 intin[3] h_align 

intin+8 intin [4] v_align 

intin+10 intin[5..n+4] filename[0..n~l] 

ptsin ptsin[0..3] xyarray[0..3] 

Parameter: 

aspect: Aspect Ratio (Abbildungsmaßstab) 

0; Aspect Ratio wird ignoriert 

1: Pixel werden berücksichtigt (z.B. werden Kreise wieder auf Kreise ab¬ 

gebildet) 

x_scale: Skalierung der X-Achse (0: gebrochen (exakter), 1: ganzzahlig) 

y„scale: Skalierung der Y-Achse (0: gebrochen (exakter), 1: ganzzahlig) 

h_align: horizontale Ausrichtung (0: links, 1: zentriert, 2: rechts) 

v_align: vertikale Ausrichtung (0: oben, 1: zentriert, 2: unten) 

xyarray[0]: ggf. X-Koordinate der oberen linken Ecke des Ausgaberechteckes 

xyarray[l]: ggf. Y-Koordinate der oberen linken Ecke des Ausgaberechteckes 

xyarray[2]: ggf. X-Koordinate der unteren rechten Ecke des Ausgaberechteckes 

xyarray[3]: ggf. Y-Koordinate der unteren rechten Ecke des Ausgaberechteckes 
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INQUIRE PRINTER SCAN (VDI5, Escape 24) (Drucker) 

Erlaubt die Abfrage verschiedener druckerspezifischer Parameter. 


Deklaration in C: 

void vq_scan (WORD handle, WORD *g_slice, WORD *g__page, 

WORD *a_slice, WORD *a_page, WORD *div_fac) 

{ 

contrl[0] = 5; 

contrl[1] = contrl[3] = 0; 

contrl[5] = 24; 

contrl[6] = handle; 

vdi () ; 

*g_slice = intout[0]; 

*g_page = intout[l]; 

*a_slice = intout[2]; 

*a_page = intout[3]; 

*div_fac = intout[4]; 

} 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

5 Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 # Einträge in ptsin 

contrl+4 

contrl [2] 

0 # Einträge in ptsout 

contrl+6 

contrl[3] 

0 # Einträge in intin 

contrl+8 

contrl [4] 

5 # Einträge in intout 

contrl+10 

contrl[5] 

24 VQ_SCAN 

contrl+12 

contrl[6] 

handle Gerätekennung 

intout 

intoutfO] 

g_slice 

intout+2 

intout[l] 

g-Page 

intout+4 

intout[2] 

a_slice 

intout+6 

intout[3] 

a_page 

intout+8 

intout[4] 

div_fac 
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Parameter: 

g_slice: Der Druckertreiber unterteilt die Druckseite in mehrere “Scheiben” (engl.: 

slices), die nacheinander formatiert und gedruckt werden, um den Speicheiplatz- 
bedarf zu senken. “g_slice” ist die Anzahl dieser Scheiben. 
g_page: Pixelhöhe einer Scheibe 

a_slice: Höhe einer Textzeile in Pixeln 

a_.page: Textzeilen pro Seite 

div_fac: Durch diesen Faktor müssen die anderen Werte ggf. noch geteilt werden. 
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OUTPUT ALPHA TEXT (VDI5, Escape 25) (Drucker, Metafile) 


Erlaubt die Ausgabe einfachen Textes (nicht im Grafikmodus) an der aktuellen Position des 
Druckkopfes. Grundlegende Steuerfunktionen sind filr alle Druckertypen genormt. 

Deklaration in C: 

void v_alpha_text (WORD handle, const char *string) 

{ 

WORD *tmp; 
tmp = intin; 

while (*trrp++ = *string++) ; 
contrl[0] = 5; 
contrl[l] = 0; 

contrl(3] = ((int)(tmp-intin)-1); 
contrl[5] = 25; 
contrl[6] = handle; 
vdi (); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl [3] 

n 

# Einträge in intin 

contrl+8 

contrl[4] 

5 

# Einträge in intout 

contrl+10 

contrl[5] 

25 

V_ALPHA_TEXT 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin[0..n-l] 

string[0.,n-l] 


Parameter: 

string: auszugebender Text. Dabei sind folgende Steuerzeichen genormt: 
DC2 0: Fett an 

DC2 1: Fett aus 

DC2 2: Italic an (Schrägschrift) 
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DC2 3: Italic aus 

DC2 4: Unterstrichen an 

DC2 5: Unterstrichen aus 

DC2 6: Superscript an 

DC2 7: Superscript aus 

DC2 8: Subscript an 

DC2 9: Subscript aus 

DC2 A: Briefqualität-Modus an (LQ, NLQ) 

DC2 B: Briefqualität-Modus aus 

DC2 C: Breitschrift an 

DC2 D: Breitschrift aus 

DC2 E: Helle Schrift an 

DC2 F: Helle Schrift aus 

DC2 G bis 

DC2 V: reserviert, werden vom Treiber ignoriert 

DC2 W: Pica-Schrift (10 cpi) 

DC2X: Elite-Schrift (12 cpi) 

DC2 Y: komprimierter Druck 

DC2 Z: Proportionalschrift 

Ferner wird der Formfeed (Seitenvorschub) mit dem ASCII-Wert 12 unterstützt. Der String 

ist bei C-Binding nullterminiert. 

Bemerkungen 

Bei “DC2” handelt es sich um den ASCII-Wert 18. 

Das OUT-Dateiformat (das von “OUTPUT” für PC-GEM gelesen wird) benutzt zusätzlich zu 

den genannten Control-Sequenzen das Kommando 

(ESC)(ESC)GEH,x,y,w,h,D:\PATHNAME\FILENAME.EXT 


um Grafiken in den Ausdruck einzubinden. Bei ESC handelt es sich um den ASCII-Wert 27. 
x, y, w und h sind in Zeicheneinheiten relativ zur aktuellen Cursorposition anzugeben. 
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SELECT PALETTE (VDI5, Escape 60) (IBM-CGA) 


Diese Funktion ermöglicht die Auswahl der Farbpalette auf einer IBM-CGA-Grafikkarte in 
mittlerer Auflösung. 


Deklaration in C: 

WORD vs_jsalette (WORD handle, WORD palette) 
{ 

contrl[0] =5; 
contrl[l] = 0; 
contrl[3] = 1; 
contrl[5] - 60; 
contrl[6] = handle; 
intin[0] = palette; 
vdi (); 

return intout [0]; 


GEM-Arrays: 


Adresse 

Feideiement 

Belegung 

contrl 

contrl[0) 

5 

Opcode für ESCAPE 

contrl+2 

contrl |T1 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

1 

# Einträge in intin 

contrl+8 

contrl[4] 

1 

# Einträge in intout 

contrl+10 

contrl[5] 

60 

VS_PALETTE 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

intin 

intin [0] 

palette 


intout 

intout[0J 

Retum-Wert 


Parameter; 

palette: Farbpalettenwahl (0: Rot, Grün, Braun (default); 1: Cyan, Magenta, Weiß) 

vs_palette(): ausgewählte Palette 

Bemerkungen 

Vermutlich die überflüssigste Funktionsbeschreibung des Profibuchs. 
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GENERATE SPECIFIED TONE 

(VDI5, Escape 61) (Bildschirm) - nur in PC-GEM ab Version 2.0 


Erzeugt einen Ton mit der angegebenen Länge und Tonhöhe. 


Deklaration in C: 

void v_sound {WORD handle, WORD frequency, WORD duration) 
{ 

contrl[0] = 5; 
contrl[l] = 0; 
contrl[3] = 2; 
contrl[5] = 61; 
contrl[6] - handle; 
intin[0) ~ frequency; 
intinfl] = duration; 
vdi {); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contri[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

2 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+10 | 

contrl [5] 

61 

V_SOUND 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin [0] 

frequency 

intin+2 

intin[l] 

duration 


Parameter: 

frequency: Tonhöhe in Hertz 

duration: Dauer in Timer-Ticks 

Bemerkungen 

Im ROM-Bildschirmtreiber nicht implementiert. 
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SET/CLEAR TONE MUTING FLAG (VDI 5, Escape 62) 
(Bildschirm) - hur in PC-GEM ab Version 2.0 


Setzt oder löscht das Tonflag oder liefert dessen Status zurück. 

Deklaration in C: 

WORD vs_mute (WORD handle, WORD action) 

1 

contrl[0] = 5; 
contrlfl] = 0; 
contrl[3] =1; 
contrl[5] = 62; 
contrl[6] = handle; 
intin[0] = action; 
vdi (); 

return intout[0]; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

1 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

62 

VS_MUTE 

contrl+12 

contrl[6] 

handle Gerätekennung 

intin 

intin [0] 

action 


intout 

intout[0] 

Return-Wert 


Parameter: 

action: MUTE„RBTURN (-1): Status abfragen 

MUTE_ENABLE (0): Tonerzeugung ein 

MUTE_DISABLE (1): Tonerzeugung aus 

vs_mute(): Tonerzeugung an (0) oder aus (ungleich 0) 

Bemerkungen 

Im ROM-Bildschirmtreiber nicht implementiert. 
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SET TABLET AXIS RESOLUTION IN LINES/INCH 
(VDI5, Escape 81) (Grafik-Tablett) 


Setzt horizontale und vertikale Auflösung des Grafiktabletts. 


Deklaration in C: 


void vt_resolution (WORD bandle, WORD xres, WORD yres, 
WORD *xset, WORD *yset) 

{ 

contrl[0] = 5; 
contrl[1] = 0; 
contrl[3] = 2; 
contrl[5] = 81; 
contrl[6] = handle; 
intin[0] = xres; 
intin[l] = yres; 
vdi (); 

*xset = intout[0]; 

*yset = intout [ 1]; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

5 

Opcode für ESCAPE 

contrl+2 

contrlfl] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

2 

# Einträge in intin 

contrl+8 

contrl[4] 

2 

# Einträge in intout 

contrl+10 

contrl[5] 

81 

VT_RESOLUTION 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

intin 

intinfO] 

xres 


intin+2 

intinfl] 

yres 


intout 

intoutfO] 

xset 


intout+2 

intoutfl] 

yset 



Parameter: 

xres, yres: Auflösung in Zeilen pro Zoll (lpi) 
xset, yset: gesetzte Auflösung 
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SET TABLET AXIS RESOLUTION IN LINES 
(VDI 5, Escape 82) (Grafik-Tablett) 


Setzt horizontale und vertikale Auflösung des Grafiktabletts. 

Deklaration in C: 

void vt_axis (WORD handle, WORD xres, WORD yres, WORD *xset, 
WORD *yset) 

{ 

contrl[0] = 5; 
contrl[1] = 0; 
contrl[3] = 2; 
contrl[5] = 82; 
cont r1[6] = handle; 
intin[0] = xres; 
intin[1] = yres; 
vdi (); 

*xset = intout[0]; 

*yset = intout[1]; 

1 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

5 

Opcode für ESCAPE 

contrl+2 

contrlfl] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl [3] 

2 

# Einträge in intin 

contrl+8 

contrl[4] 

2 

# Einträge in intout 

contrl+10 

contrl [5] 

82 

VT_AXIS 

COntrl+12 

contrl [6] 

handle 

Gerätekennung 

intin 

intin [0] 

xres 


intin+2 

intinfl] 

yres 


intout 

intoutfO] 

xset 


intout+2 

intoutfl] 

yset 



Parameter: 

xres, yres: Auflösung in Zeilen 
xset, yset: gesetzte Auflösung 
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SET TABLET X AND Y ORIGIN 
(VDI5, Escape 83) (Grafik-Tablett) 


Setzt den Ursprung des Koordinatensystems. 


Deklaration in C: 

void vt_origin (WORD handle, WORD xorigin, WORD yorigin) 


contrl[0] = 5; 
contrl[1] = 0; 
contrl[3] = 2; 
contrl[5] = 83; 
contrl[6] = handle; 
intin[0] = xorigin; 
intin[1] = yorigin; 
vdi (); 


GEM-Arrays: 


Adresse 

Feidelement 

Belegung 

contrl 

contrlfO] 

5 

Opcode für ESCAPE 

contrl+2 

contrlf 1] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

2 

# Einträge in intin 

contrl+8 

contrl [4] 

2 

# Einträge in intout 

contrl+10 

contrl [5] 

83 

VT_ORIGIN 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin [0] 

xorigin 


intin+2 

intinfl] 

yorigin 



Parameter: 

xorigin: X-Koordinate der linken oberen Ecke 

yorigin: Y-Koordinate der linken oberen Ecke 
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(VDI5, Escape 84) (Grafik-Tablett) 


Liefert die Ausmaße des Grafiktabletts in I/10-ZoIl. 


Deklaration in C: 

void vq_tdimensions (WORD handle, WORD *xdimension, 

WORD *ydimension) 

1 

contrl[0] = 5; 

contrl[1] = contrl[3] = 0; 

contrl[5] = 84; 

contrl[6] = handle; 

vdi (); 

*xdimension = intinfO]; 

*ydimension = intinfl]; 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [01 

5 

Opcode für ESCAPE 

contrl+2 

contrlfl] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

2 

# Einträge in intout 

contrl+10 

contrl[5] 

84 

VQ_TDIMEN SIONS 

contrl+12 

contrlfö] 

handle Gerätekennung 

intout 

intoutfO] 

xdimension 

intout+2 

intoutfl] 

ydimension 


Parameter: 

xdimension: Breite in 1/10 Zoll 
ydimension: Höhe in 1/10 Zoll 
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SET TABLET ALIGNMENT (VDI5, Escape 85) (Grafik-Tablett) 


Dient der Ausrichtung des Koordinatensystems innerhalb eines Ausschnitts des Grafiktabletts. 


Deklaration in C: 

void vt_alignment (WORD handle, WORD dx, WORD dy) 
{ 

contrl[0] = 5; 
contrl[l] = 0; 
contrl[3] = 2; 
contrl[5] = 85; 
contrl[6] = handle; 
intin[0] = dx; 
intin[l] = dy; 
vdi (); 

} 


GEM-Arrays; 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

5 

Opcode für ESCAPI 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

2 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrl [5] 

85 

VT_ALIGNMENT 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

intin 

intin[0] 

dx 


intin+2 

intin[l] 

dy 



Parameter: 

dx, dy: Offset in X- und Y-Koordinate vom Ursprung. 
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SET CAMERA FILM TYPE AND EXPOSURE TIME 
(VDI5, Escape 91) (Polaroid Palette) 


Legt Filmtyp und Belichtungszeit fest. 

Deklaration in C: 

vöid vsp^film (WORD handle, WORD index, WORD lightness) 

{ 

contrl[0] = 5; 
contrl[l] = 0; 
contrl[3] = 2; 
contrl[5] = 91; 
contrl[6] = handle; 
intin[0] = index; 
intin[l] = lightness; 
vdi (); 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

2 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

91 

VSP_FILM 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin+2 

intin [0] 
intin[l] 

index 

lightness 


Parameter: 

index: Nummer des Filmtyps (siehe “vqp_filmname()”) 

lightness: Belichtungszeit von -3 bis 3 (-3: halbe, 0: normal, 3: doppelte); mit jeder 

ganzen Zahl mehr wird die Blendenzahl um ein Drittel erhöht. 
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INQUIRE CAMERA FILM NAME 
(VDI5, Escape 92) (Polaroid Palette) 


Liefert zu einer Filmnummer den entsprechenden Namen (maximal 24 Zeichen). Bei einer 
falschen Filmnummer erhält man einen Nullstring als Ergebnis. 


Deklaration in C: 

WORD vqp_filmname (WORD handle, WORD index, char *name) 
{ 

WORD tmp; 
contrl(0] = 5; 
contrl[l] = 0; 
contrl[3J = 1; 
contrl[5] = 92; 
contrl[6] = handle; 
intin[0] = index; 
vdi (); 

for (tmp=0; tmp<contrl[4]; tmp++) 
name[tmp] = intout[tmp]; 
return contrl[4]; 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

5 

Öpcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

1 

# Einträge in intin 

contrl+8 

contrl(4] 

Status 

# Einträge in intout 

contrl+10 

contrl [5] 

92 

VQP_FILMNAME 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin[0] 

index 


intout 

intout[0..24] 

name[0..24] 


Parameter: 

index: Nummer des Filmtyps 

name: Name des Films (nullterminiert) 

vqp_filmname(): 0: falsche Nummer übergeben 
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DISABLE OR ENABLE FILM EXPOSURE FOR FRAME 
I PREVIEW (VDI5, Escape 93) (Polaroid Palette) 


Bei Kameratypen mit Preview-Möglichkeit kann man mit dieser Funktion die Belichtung 
abschalten. 


Deklaration in C: 


void vsc_expose (WORD handle, 
{ 


intin[0] = 

= state; 

contrl[0] 

= 5; 

contrl[1] 

= 0; 

contrl[3] 

- 1; 

contrl[5] 

* 93; 

contrl[6] 

= handle; 

vdi (); 



WORD state) 


} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

5 

Opcode für ESCAPE 

contrl+2 

contrlfl] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl [3] 

1 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

93 

VSC_EXPOSE 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin[0] 

state 



Parameter: 

state: 0: Belichtung abschalten 

sonst: Belichtung einschalten 
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UPDATE METAFILE EXTENTS (VDI5, Escape 98) (Metafiles) 


Mit dieser Funktion werden die Größen-Informationen im Metafile-Kopf erneuert. 

Die Größen-Information kann man benutzen, um schnell die minimalen oder maximalen 
Ausmaße aller im Metafile abgespeicherten Primitiven zu ermitteln. 

Deklaration in C; 

void v_meta_extents (WORD handle, WORD min_x, WORD min_y, 

WORD max_x, WORD max_y) 

{ 

ptsin[0] = rain_x; 
ptsin[lj = min_y; 
ptsin[2] = max_x; 
ptsin[3] = max_y; 
contrl[0] = 5; 
contrl[1] = 2; 
contrl[3] = 0; 
contrl[5] = 98; 
contrl[6] = handle; 
vdi () ; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

5 

Opcode für ESCAPE 

contrl+2 

contrlfl] 

2 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

0 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+10 

contrl [5] 

98 

V_META_EXTENTS 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

ptsin 

ptsin [0] 

min_x 


ptsin+2 

ptsin[l] 

min_y 


ptsin+4 

ptsin [2] 

max_x 


ptsin+6 

ptsin[3] 

max_y 
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Parameter: 

min_x: minimaler X-Wert des minimalen umgebenden Rechteckes 

min_y: minimaler Y-Wert des minimalen umgebenden Rechteckes 

max_x: maximaler X-Wert des minimalen umgebenden Rechteckes 
max_y: maximaler Y-Wert des minimalen umgebenden Rechteckes 
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WRITE METAFILE ITEM (VDI5, Escape 99) (Metafiles) 


Die mit dieser Funktion in ein Metafile geschriebenen Parameter werden mit einem Opcode 
als benutzerdefinierte Gegenstände abgespeichert. Intin[0] enthält einen benutzerdefinierten 
Sub-Opcode. 

Die Nummern 0 bis 100 sind reserviert, als Sub-Opcode kommen also Nummern ab 101 in 
Frage. 

Diese Funktion wird beispielsweise von “GEM Draw” (Digital Research) benutzt, um zu 
Gruppen zusammengefaßte Objekte zu markieren. 

Deklaration in C: 

void v_write_meta (WORD handle, WORD num_intin, WORD *a_intin, 

WORD *num_ptsin, WORD *a_ptsin) 

t 

iioff = a_intin; 
pioff = a_ptsin; 
contrl[0] - 5 ; 
contrl[l] = num_ptsin; 
contrl[3] = num_intin; 
contrl[5] = 99; 
contrl[6] = handle; 
vdi (); 

iioff = intin; 
pioff = ptsin; 

} 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

num_ptsin 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

num_intin 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

99 

V_WRITE_META 

contrl+12 

contrl [6] 

handle 

Gerätekennung 
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Parameter: 


nurnjntin: 
numjptsin: 
int_in[0]: 
intinfl] bis 
intintnum_intin-l ]: 
ptsinfO] bis 
ptsin[num_ptsin-l ]: 


Anzahl der Werte im Intin-Array 
Anzahl der Werte im Ptsin-Array 
benutzerdefinierter Sub-Opcode 

benutzerdefinierte Information 

benutzerdefinierte Information 


Bemerkungen 

Von “GEM Draw” benutzte Opcodes: 


START GROUP (10) 

END GROUP (11) 

SET NO LINE STYLE (49) 

SET ATTRIBUTE SHADOW ON (50) 


Beginn einer Gruppe 

Ende einer Gruppe 

Jeglichen Linienstil ausschalten 

Alle bis “SHADOW OFF” folgenden Befehle 

werden benutzt, um für das erste Objekt danach 

einen Schatten zu zeichnen. 


SET ATTRIBUTE SHADOW OFF (51) Siehe oben 
START DRAW AREA PRIMITIVE (80) Beginn einer Füllfläche 
END DRAW AREA PRIMITIVE (81) Siehe oben 
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PHYSIGAL PAGE SIZE (VDI5, Escape 99, Opcode 0) (Metafdes) 


Setzt die Seitengröße in 1/10 mm. 

Deklaration in C: 

void vmjpagesize (WORD handle, WORD pgwidth, WORD pgheight) 
{ 

contrl[0] = 5; 
contrl[l] = intin[0J = 0; 
contrl[3] = 3; 
contrl[5] = 99; 
contrl[6] = handle; 
intin[1] = pgwidth; 
intin[2] = pgheight; 
vdi (); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[ 1] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

3 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

99 

V_WRITE_META 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin [0] 

0 

VM_PAGESIZE 

intin+2 

intin[l] 

pgwidth 

intin+4 

intin[2] 

pgheight 


Parameter: 

pgwidth: Breite in 1/10 mm 

pgheight: Länge in 1/10 mm 
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COORDINATE WINDOW (VDI 5, Escape 99, Opcodc 1) (Metafiles) 


Setzt das benutzte Koordinatensystem für die Seite. 

Deklaration in C: 


void vm_coords 
{ 

contrl[0] 
contrl[1] 
contrl[5] 
contrl [6] 
intin[0] ! 
intin[1] = 
intin[2] = 
intin[3] : 
intin[4] : 
vdi (); 


(WORD handle 
WORD ury) 

= contrl[3] 5 
= 0 ; 

= 99; 

= handle; 

■ i; 

= llx; 

= iiy; 

- urx; 

5 ury; 


WORD llx, WORD 

5; 


lly, WORD urx, 


} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrI+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

5 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrlt 10 

contrl[5] 

99 

V_WRITE__META 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin[0] 

1 

VM_COORDS 

intin+2 

intin[l] 

llx 


intin+4 

intin[2] 

lly 


intin+6 

intin[3] 

urx 


intin+8 

intin[4] 

ury 







VDI-Betriebssystemroutinen 


527 


Parameter: 

llx: X-Koordinaten links unten 

Hy: Y-Koordinaten links unten 

urx: X-Koordinaten rechts oben 

ury: Y-Koordinaten rechts oben 
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CHANGE GEM VDI FILE NAME (VD15, Escape 100) (Metafües) 


Diese Funktion benennt ein Metafile von “GEMFILE.GEM” in einen anderen Namen unter 
Beibehaltung der Extension “GEM” um. Ein Pfadname (mit Laufwerksbezeichnung) zur 
Auffindung des Files kann mit angegeben werden. Sollte “CHANGE GEM VDI FILE 
NAME” nicht sofort nach Aufruf der Funktion “OPEN WORKSTATION” (VDI 1) benutzt 
werden, so bleibt der Aufruf wirkungslos. Ein eventuell geöffnetes Metafile wird geschlossen. 

Deklaration in C: 

void vm_filename (WORD handle, const char *filename) 

{ 

WORD *tmp; 
tmp = intin; 

while (*tmp++ = *filename++); 
contrl[0] = 5; 
contrl[l] = 0; 

contrl[3] = ((int) (tmp-intin)-1); 
contrl[5] = 100; 
contrl[6] = handle; 
vdi () ; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

eontrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

n 

# Einträge in intin 

contrl+8 

contrl [4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

100 

VMJFILENAME 

contrl+12 

contrl[6] 

handle 

Gerätekennung 

intin 

intin[0..n-l] 

filename[0..n-l] 


Parameter: 


n: Länge des Intin-Arrays (1 bis 74) 

filename: Dateispezifikation des Metafiles (muß mit dem ASCII-Wert 0 enden). 




VDI-Betriebssystemroutinen 


529 


SET LINE OFFSET (VDI5, Escape 101) (ROM-Bildschirmtreibfer) 


Setzt den Offset in Rasterzeilen zum Beginn des logischen Bildschirms (normalerweise 0). 
Diese Funktion ist in keiner offiziellen Dokumentation beschrieben - Benutzung auf eigene 
Gefahr! 


Deklaration in C: 


void v_offset (WORD handle, WORD offset) 
{ 


intin[0] = offset; 
contrl[0] = 5; 
contrl[l] = 0; 
contrl[3] = 1; 
contrl[5] = 101; 
contrl[6] = handle; 
vdi <); 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl[2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

1 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

101 

V_OFFSET 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

intin 

intin[0] 

offset 



Parameter: 

offset: Anzahl der Rasterzeilen unterhalb der oberen Bildschirmkante, von der ab der 
logische Bildschirm beginnen soll. 
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INIT SYSTEM FONT (VDI5, Escape 102) (ROM-BUdschirmtreiber) 


Diese Routine installiert den angegebenen Zeichensatz als Systemzeichensatz. Eigene 
Versuche ergaben, daß die Zeichenbreite konstant acht Pixel betragen und der Zeichensatz im 
Motorola-Format vorliegen muß (siehe Font-Header)! Diese Funktion ist nirgendwo offiziell 
dokumentiert - daher Verwendung auf eigene Gefahr! 


Deklaration in C: 

void v_fontinit (WORD handle, WORD fh_high, WORD fh__low) 

{ 

intin[0] = fhjiigh; 
intin[l] = fh_low; 
contrl[0] = 5; 
contrl[l] = 0; 
contrl[3] = 2; 
contrl[5] = 102; 
contrl[6] = handle; 
vdi (); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrlfO] 

5 

Opcode für ESCAPE 

contrl+2 

contrlfl] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl[3] 

2 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

102 

V_FONTINIT 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

intin 

intin[0/l] 

font_hdr 


Parameter; 

font_hdr: Zeiger auf den Zeichensatzkopf. 
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ESCAPE 2000 (VDI5, Escape 2000) (Atari SLM-Laser-Drucker) 

Diese Spezialfunktion für die Atari-SLM-Laserdrucker druckt beliebig viele Kopien der 
laufenden Seite. 

Deklaration in C: 

void v_escape2000 (WORD handle, WORD times) 

{ 

intin[0] = times; 
contrl[0] =5; 
contrl[l] = 0; 
contrl[3] = 1; 
eontrl[5] = 2000; 
contrl[6] = handle; 
vdi (); 

} 


GEM-Arrays: 

Adresse | Feldelement j 

Belegung 

contrl 

contrlfO] 

5 

Opcode für ESCAPE 

contrl+2 

contrl[l] 

0 

# Einträge in ptsin 

contrl+4 

contrl [2] 

0 

# Einträge in ptsout 

contrl+6 

contrl [3] 

1 

# Einträge in intin 

contrl+8 

contrl[4] 

0 

# Einträge in intout 

contrl+10 

contrl[5] 

2000 

V_ESCAPE2000 

contrl+12 

contrl [6] 

handle 

Gerätekennung 

intin 

intin [0] 

times 



Parameter: 

times: Anzahl der zusätzlich zu druckenden Kopien 
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Kapitel 4: AES-Betriebssystemroutinen 

Einleitung 

Die AES (“Application Environment Services”) sind die obere Schicht des GEM, Sie befassen 
sich mit all jenen GEM-Bestandteilen, die über elementare Grafikausgaben (und -eingaben) 
hinausgehen. Es werden ausschließlich VDI- und GEMDOS-Aufrufe benutzt, und so sind die 
AES sowohl von Grafikhardware (VDI), vom Eingabegerät (VDI) als auch vom Dateisystem 
(GEMDOS) unabhängig. Die Entwicklung der AES reicht in das Jahr 1984 zurück, als es von 
Digital Research zunächst für MS-DOS-Rechner entwickelt wurde und später auf die Apple 
Lisa (unter CP/M 68K) portiert wurde. Diese Version wurde dann anschließend auf den Atari 
ST (unter GEMDOS) portiert. 


Die verschiedenen GEM-Versionen 

GEM« V ersionsnummern 

Als GEM-Versionsnummer wird normalerweise die bei “appl_init()” vom AES (im “Global”- 
Feld) zurückgelieferte Kennung benutzt. Das VDI hingegen hat eigentlich keine eigene 
Versionsnummer, zumal das Verhalten der einzelnen VDI-Fünktionen hauptsächlich von den 
benutzten Gerätetreibern (die ja weitestgehend austauschbar sind) bestimmt wird. 


GEM 1.x 

Diese erste AES-Version (1 .x) hatte nicht von ungefähr sehr auffällige Ähnlichkeiten mit dem 
Betriebssystem des Apple Macintosh. Das äußerte sich nicht nur im Design der Fensterele¬ 
mente, sondern auch in vielen Eigenschaften des Desktops und anderer Anwendungspro¬ 
gramme. Damals wurde GEM meist im Zusammenhang mit Testversionen von “GEM- 
Draw”, “GEM-Paint” und “GEM-Write” gezeigt, die in vielen Details den bekannten Mac- 
Vorbildem “MacDraw”, “MacPaint” und “MacWrite” entsprachen. 

Dies ist auch die GEM-Version, die schließlich von Atari übernommen und im ST ausgeliefert 
wurde. Nicht ganz fertige Testversionen der “Vorbildprogramme” werden noch bis heute 
benutzt. Auf dieser Fassung beruhen auch alle neueren Atari-GEM-Versionen. Atari hat 
damals nämlich alle Rechte an der bestehenden Version erworben und die Entwicklung selbst 
fortgeführt. Damit lassen sich auch die immer weiter “klaffenden” Unterschiede zwischen 
Atari-GEM und PC-GEM erklären. 
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GEM 2.x 

Wie man sich denken kann (“nachher ist man immer schlauer”) kam es zu einer juristischen 
Auseinandersetzung zwischen Apple und Digital Research, bei der es allerdings in erster Linie 
um das Outfit der Anwendungsprogramme und des Desktops ging. 

Die Einigung, die Ataris GEM-Version nicht betraf, sah folgendermaßen aus: 

Einige Fensterelemente wurden so verändert, daß sie nicht mehr ganz so wie Mac- 
Fenster aussahen (in erster Linie der Titelbalken). 

- Das Accessory-Menü wanderte in die gegenüberliegende Bildschirmecke. 

- Die sogenannten “Grow-” und “Shrink-Boxes” wurden eliminiert. 

- Das Desktop wurde völlig neu programmiert und auf zwei feste Fenster festgelegt. 
Entgegen landläufiger Meinung war das allerdings nur eine Änderung im Desktop, nicht 
in den AES (die weiterhin bis zu acht überlappende Fenster erlauben). 

Doch es gab nicht nur Einschränkungen, sondern auch Verbesserungen. Als wichtiges Beispiel 
sei nur erwähnt, daß Accessories eigene Menüleisten anmelden dürfen. 

Diese Version erhielt die Versionsnummer 2.0 und wird seit 1987 ausgeliefert. Nur wenig 
später wurde sie von dem niederländischen Softwarehaus “ABC” zusammen mit “GEM- 
Draw”, “GEM-Paint”, “GEM-Graph” und natürlich “GEM-Desktop” auf den Atari portiert. 
Leider erlangte diese Version nie große Bedeutung und ist heute nicht mehr erhältlich. 

Alle für GEM 2.x spezifischen Informationen sind im folgenden mit einem Zusatz wie “nur 
in PC-GEM ab Version 2.0” versehen. 


PC-GEM 3.x 

In dieser Version sind nur noch geringfügige Verbesserungen vorgenommen worden (das 
Menüverhalten läßt sich von “Drop-Down” auf “Pull-Down” umschalten). 

Mittlerweile wird PC-GEM nicht mehr von Digital Research selbst weiterentwickelt, und so 
sind angesichts der Dominanz von Microsoft Windows im PC-Bereich wohl keine größeren 
Neuerungen mehr zu erwarten. Teile von GEM und Desktop sind allerdings in die grafische 
Benutzeroberfläche “ViewMax” eingeflossen, die von Digital Research als Zubehör zu “DR- 
DOS 5.0” für PCs ausgeliefert wird. 
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Atari-GEM 1.4 

Wichtige Änderungen hat Atari erst im GEM 1.4 im TOS 1.04 vorgenommen. Bekannteste 
Auswirkung ist die stark verbesserte Dateiauswahlbox. 


Atari-GEM 3.x 

Die Erweiterungenim Atari-GEM 3 .x (verstellbare Farben und Muster für die Fensterelemente) 
hätten diese hohe Versionsnummer eigentlich nicht gerechtfertigt. Offenbar wollten die 
Programmierer absolut klar machen, daß Atari nicht gewillt ist, weiter zu PC-GEM kompatibel 
zu bleiben oder gar die dort vorgenommenen Änderungen nachzuvollziehen. Eine der Verän¬ 
derungen im Atari-GEM ist bereits jetzt zum PC-GEM inkompatibel (neue Funktionsnummer 
bei “wind_set()"). 


Künftige Weiterentwicklungen 

Es ist immer schwierig, in die Zukunft zu schauen. Doch bereits existierende Weiterentwick¬ 
lungen wie X/GEM (ein erweitertes GEM für DR’s Multitasking-System “Flex-OS”) oder 
Multi-GEM (ein “Hack” für Atari-GEM von der Maxon GmbH) zeigen schon jetzt, daß das 
Marschziel dem sehr nahe kommen wird, was Mac-Benutzer als den “Multi-Finder” kennen: 
AES, die mehr als ein Hauptprogramm gleichzeitig ausführen können. Auch Ataris eigene 
Pläne gehen sicherlich in eben diese Richtung. 

Wer neue GEM-Programme entwickelt, sollte diese möglichen Weiterentwicklungen immer 
im Kopf haben! 


Die AES und Multitasking 


Begriffserklärungen 

Die aktuelle Version der AES erlaubt die gleichzeitige Abarbeitung von bis zu acht AES- 
Prozessen. Das klingt vielleicht zunächst etwas verblüffend, daher erst einmal ein paar 
Begriffserklärungen: 

Auf einem Rechner mit nur einer CPU können natürlich niemals mehrere Programme wirklich 
gleichzeitig ausgeführt werden. Die Rechenzeit muß also möglichst geschickt auf die ver¬ 
schiedenen Aufgaben verteilt werden. 
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Bei “pre-emptivem” Multitasking wird jedem Prozeß ein bestimmtes Quantum Zeit zugestan¬ 
den. Nach Ablauf dieser Frist wird dann automatisch auf den nächsten Prozeß weitergeschaltet. 
Dabei sind natürlich noch etliche Verfeinerungen wie unterschiedliche Prioritäten oder das 
“Blocken” von Funktionen (so könnte beispielsweise ein Prozeß so lange blockiert bleiben, 
bis ein Tastendruck gemeldet wird) möglich. Dieses Multitasking-Konzept wird zum Beispiel 
in allen Unix-Versionen und verwandten Betriebssystemen benutzt. 

Beim “kooperativen” Multitasking wird ein etwas anderer Weg gegangen: Jeder Prozeß erhält 
quasi die volle Kontrolle über das Rechnersystem, die er dann irgendwann freiwillig wieder 
abgibt. Damit ist auch schon der Hauptnachteil klar: Ein fehlerhaftes Programm kann das 
gesamte System zum Erliegen bringen. Andererseits wird möglichst wenig Zeit mit überflüs¬ 
sigen Prozeßwechseln verbracht. 

Ein weiteres wichtiges Stichwort heißt “Ereignisorientierung”. In ereignisorientierten Syste¬ 
men teilen die einzelnen Prozesse dem Betriebssystem mit, auf welche Art von Ereignissen 
(wie dem Verstreichen einer Zeitspanne oder eine Tastatureingabe) sie warten. Mit Hilfe die¬ 
ser Infonnation kann das Betriebssystem die Prozessorzeit sehr effektiv verteilen. 

Digital Research hat für die AES ein kooperatives, ereignisorientiertes Multitasking ausge¬ 
wählt. Umschaltungen zwischen AES-Prozessen finden immer nur dann statt, wenn ein 
Prozeß freiwillig die Kontrolle abgibt, sprich einen AES-Aufruf tätigt. Ansonsten verbringen 
die allermeisten GEM-Programme ihre Zeit mit dem Warten auf ein Ereignis - ob ein Tasten¬ 
druck, eine Fenstermanipulation oder etwas anderes. 

In den aktuellen Versionen des Atari-GEM können insgesamt acht verschiedene AES- 
Prozesse gleichzeitig ablaufen. Einer davon ist immer das “Hauptprogramm”, und sechs 
weitere "Slots” (also Platzhalter für Prozesse) sind für bis zu sechs Accessories reserviert. Der 
achte im Bunde ist der “Screen-Manager”, der für die Fensterelemente und die Drop-Down- 
Menüs zuständig ist. 


Der Dispatcher 

Die Verteilung der Prozessorzeit wird vom Dispatcher übernommen. Um Überblick und 
Gerechtigkeit zu wahren, legt er zwei Listen an, in denen alle Prozesse, die bereit zum Ablauf 
sind (READY-LIST), und alle, die auf ein Ereignis warten (NOT-READY-LIST), verzeichnet 
sind. 

Wie geht der Dispatcher nun vor? Zunächst genehmigt er dem Prozeß, der in der READY- 
Liste ganz vome steht, einen “Durchgang”: Das heißt, er wartet darauf, daß dieser Prozeß 
irgendwann mal wieder einen AES-Aufruf tätigt. Daher sollte man es sich zur Angewohnheit 
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machen, in Programmschleifen, die völlig ohne AES-Aufrufe auskommen, den einen oder 
anderen “evnt_timer()”-Aufruf einzustreuen. 

Ist nun wieder der Dispatcher am längeren Hebel, prüft er zunächst, ob eines der Ereignisse, 
auf das die Prozesse in der NOT-READY-Liste so sehnsüchtig warten, eingetreten ist. In 
diesem Fall wird der betreffende Prozeß von der NOT-READY-Liste an das Ende der 
READY-Liste gesetzt. 

Weiterhin ist zu betrachten, ob nun möglicherweise der zuletzt aktive Prozeß auf ein Ereignis 
wartet. In einem solchen Fall wird er an das Ende der NOT-READY-Liste verbannt, 
andernfalls wird er das Schlußlicht der READY-Liste. 

In den aktuellen Atari-AES sind sowohl Anzahl als auch Belegung der Prozeß-Slots von 
Beginn an fest. Accessories und Screen-Manager werden nie beendet, und das Hauptprogramm 
wird nach Beendigung sofort durch ein anderes (normalerweise das Desktop) ersetzt. In 
künftigen AES-Versionen wird es vermutlich möglich sein, mehrere Hauptprogramme 
gleichzeitig zu starten-Accessories werden dadurch weitestgehend ihre Existenzberechtigung 
verlieren. 


Der Screen Manager 

Der Screen Manager ist immer aktiv und überwacht die Position des Mauszeigers, wenn dieser 
den Arbeitsbereich der Fenster anderer Applikationen verläßt. Die hier in Frage kommenden 
Flächen sind die Rahmen der Fenster, die “Drop-Dowri’-Menüs und die Menüleiste. 

Beim Berühren des Menübereichs sorgt der Screen Manager selbsttätig dafür, daß der vom 
Menü belegte Bildschirmausschnitt gesichert und anschließend wiederhergestellt wird (dazu 
wird der sogenannte “Quarter Screen Buffer” benutzt, auf den wir später zurückkommen). 

Auch Manipulationen an den Fensterkontrollen führen nicht zu dauerhaften Veränderungen 
des Bildspeichers (es werden nur jeweils die Umrisse bewegt). Resultat der Interaktionen mit 
dem Screen Manager sind die sogenannten “Mitteilungsereignisse”, die die zuständige Appli¬ 
kation über die Aktionen des Benutzers informieren. 


Einschränkungen 

Obwohl die AES viele gute Ansätze enthalten, machen sich doch Herkunft (PC unter MS- 
DOS) und Alter (1984) stark bemerkbar. Daher auch viele Einschränkungen, die die Praxis¬ 
tauglichkeit des Multitaskings in den aktuellen AES-Versionen stark einschränken. 
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Zunächst einmal muß man sich der traurigen Wahrheit stellen, daß das GEMDOS rein gar 
nichts vom Multitasking der AES weiß, Hauptprogramm und alle Accessories müssen sich für 
alle GEMDOS-Aufrufe (Speicher, Dateikennungen, DTA usw.) den gleichen GEMDOS- 
Prozeß teilen, Dadurch werden viele Projekte erheblich beschwert, zumal auch das VDI 
(Workstation öffnen, Zeichensätze laden) und viele Standard-Bibliotheksfunktionen (in C 
häufig die Benutzung der Standard-I/O-Routinen) Speicher vom GEMDOS anfordern. 

Für weitere Kopfschmerzen sorgt ein Problem, das erst in der AES-Version 3.0 beseitigt 
wurde: GEMDOS-Aufrufe können ja bekanntlich zur Alarmbox des “Critieal Error Händler” 
führen. Während die Alarmbox auf dem Bildschirm steht, kann es zu AES-Prozeßwechseln 
kommen. Wenn der ans Ruder gekommenene Prozeß nun wiederum eine GEMDOS-Funktion 
aufruft, kommt es zu einem Absturz (merke: GEMDOS ist nicht re-entrant - das heißt, 
GEMDOS-Funktionen können nicht aus GEMDOS-Funktionen heraus aufgerufen werden). 

Diese Situation kann beispielsweise dann eintreten, wenn in einem Accessory ein GEMDOS- 
Aufruf auf “evnt_timer()” folgt (Abhilfe: GEMDOS-Aufrufe mittels der Funktion 
“wind_update()” klammem, damit ist der AES-Prozeß so lange blockiert, bis die Alarmbox 
wieder verschwunden ist). 

Der Dispatcher selbst ist auch nur eingeschränkt für die Zukunft gerüstet. So sorgt er zwar für 
die Umschaltung der Prozessor-Register, nicht aber für die der FPU. Daher kann zur Zeit nur 
ein AES-Prozeß gleichzeitig FPU-Register benutzen (außer man sorgt selbst vor dem Aufruf 
von AES-Funktionen dafür, daß die Register gesichert werden). 

Wie schon erwähnt, wird die Kommunikation zwischen den verschiedenen AES-Prozessen 
über “Mitteilungen” geregelt. Die AES bedienen sich einer Warteschlange (“Message- 
Queue”), um noch nicht verschickte Mitteilungen zu speichern. Diese Queue hat in den 
existierenden AES-Versionen eine fixe Länge, so daß nicht beliebig viele Mitteilungen 
gleichzeitig “unterwegs” sein können. Daher ist spezielle Vorsicht geboten, wenn ein Prozeß 
Mitteilungen an sich selbst schickt (ein beliebter Trick zum Auslösen von “Redraws”) - ein 
Überlaufen der Message-Queue (die in den bestehenden AES-Versionen offenbar eine Länge 
von 16 Einträgen hat) führt zum Blockieren des sendenden Prozesses. 


Die Initialisierung der AES 

Aufruf nach der BlOS-Initialisierung 

In den aktuellen TOS-Versionen sind AES und Desktop zu einem gemeinsamen ausführbaren 
Programm zusammengefaßt. Dies - und nicht irgendwelche bösen Absichten - ist auch der 
Grund dafür, daß das Desktop keine echten AES-Aufrufe, sondern nur einfache Unterprogramm- 
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aufrufe macht. Das BIOS erzeugt nach Abarbeitung des AUTO-Ordners einen neuen 
GEMDOS-Prozeß und fügt als Startadresse des Text-Segments (also als Einsprungadresse) 
den Inhalt der Systemvariablen “exec_os” ein. Dort wird dann die Ausführung fortgesetzt. 


AES -Environment 

Zu Beginn wird das GEMDOS-Environment in einen eigenen Puffer fixer, beschränkter 
Länge kopiert und dort später von der Shell-Bibliothek (“shel_envm()” und “shel_find()”) 
benutzt. 


Laden der Aecessories 

An dieser Stelle wird ab Atari-GEM 3.0 ein neuer GEMDOS-Prozeß erzeugt, der später bei 
einem Auflösungswechsel wieder terminiert wird. Nur so ist es möglich, beim Wechsel der 
Auflösung wirklich allen von Aecessories belegten Speicher wieder freizugeben. Unter 
älteren GEM-Versionen blieben von Aecessories allozierte Speicherblöcke belegt, was nicht 
nur zur Reduzierung, sondern auch zur starken Zersplitterung des freien Speichers führte. 

Bei der Lokalisierung der Aecessories legen die AES ein sehr verwunderliches Verhalten an 
den Tag. Wissen sollte man, daß die AES die Aecessories immer von Laufwerk C: laden, falls 
dieses existiert und dort mindestens eine Datei mit der Namenserweiterung “ACC” gefunden 
wird. Ähnliches gilt für das Laden der “DESKTOP.INF”- bzw. “NEWDESK.INF’-Datei. 
Eine wirklich portable Methode, mit der man die AES dazu bewegen könnte, die Aecessories 
vom zum Zeitpunkt der Initialisierung aktuellen oder dem in “_bootdev” angegebenen 
Laufwerk zu laden, ist nicht bekannt. 

Es folgt der eigentliche Ladevorgang. Jede gefundene Accessory-Datei (in den aktuellen AES- 
Versionen: maximal sechs) wird mit “Pexec()” (Modus 3) geladen und reloziert. Damit wer¬ 
den die Einstellungen im Programmkopf (siehe GEMDOS-Kapitel) in Hinsicht auf das Laden 
des Prozesses sehr wohl beachtet. Anschließend wird die vom “Pexec()”-Aufruf erzeugte TPA 
mittels “Mshrink()” auf die “normale” Größe (die Summe der Längen der drei Programmseg¬ 
mente zuzüglich 256 Bytes für die Basepage) geschrumpft. 


Initialisierung der VDI-Workstation 

Anschließend öffnen die AES eine physikalische VDI-Workstation für den Bildschirm. Die 
gewünschte Bildschirmauflösung wird dabei als Gerätenummer an “v_opnwk()” übergeben 
(sehr wichtig beim Auflösungswechsel). Später gestartete Programme dürfen nur noch 
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virtuelle Bildschirm-Workstations öffnen und müssen dazu mittels “graf_handle()” die Ken¬ 
nung der von den AES benutzten physikalischen Workstation erfragen. 

Hinweis'. Alle zurZeit bekannten AES-Versionen stürzen ab, wenn der “v_opnwk()”-Aufruf 
zu einem Fehler führt. 

Damit sind insbesondere die VDI-Eingabefunktionen (die nur auf einer physikalischen Work¬ 
station benutzt werden dürfen) für die AES reserviert. Die AES benutzen das Raster¬ 
koordinatensystem des VDI. Der Ursprung liegt damit in der linken oberen Ecke des Bild¬ 
schirms. Die vom VDI gelieferten Angaben werden von den AES sauber verarbeitet. Nur 
deshalb ist es auch möglich, eigene VDI-Gerätetreiber für zusätzliche Grafikkarten zu 
installieren und dann AES und Desktop darauf laufen zu lassen. 


Der “Quarter Screen Buffer” 

Dieser Speicherbereich wird vom Screen Manager benötigt, um beim Herunterklappen von 
Drop-Down-Menüs den Inhalt des Menühintergrunds zu retten. Auch bei der Anzeige von 
Alarmboxen kommt der “QSB” (so die gebräuchliche Abkürzung) zum Einsatz. Normaler¬ 
weise sollte seine Größe von der Anzahl der Farbebenenund der Größe des Systemzeichensatzes, 
nicht aber von der Gesamtgröße des Bildschirms abhängen. Eine gute Formel wäre zum 
Beispiel: 

500 (Zeichen) * Platzbedarf eines Zeichens * Farbebenen 

Damit käme man in der Auflösung “ST-Hoch” genau auf den Wert 8000 (also ein Viertel des 
Bildspeichers). Leider sind die AES in der Praxis nicht so clever. Hier eine Übersicht über die 
verschiedenen zur Zeit benutzten Algorithmen zur Bestimmung der Puffergröße: 


GEM-Version 

Methode zum Setzen des QSB 

1.0, 1.2 

statisch, 8000 Bytes 

1.4 

dynamisch, ein Viertel des Bildspeichers 

3.0 

dynamisch, die Hälfte des Bildspeichers 


Die GEM-Versionen 1.0 und 1.2 (also bis einschließlich TOS 1.02) sind mithin nicht für Farb- 
karten vorbereitet - einer unter mehreren Gründen, warum man selbst bei Benutzung eines 
speziellen VDI-Treibers unter diesen GEM-Versionen Farbgrafikkarten nicht einsetzen kann. 

Das bei GEM 1.4 benutzte Verfahren war eigentlich sehr sinnvoll, konnte aber wegen der “TT- 
Niedrig”-Auflösung nicht beibehalten werden. Rechenexempel: Die Bildspeichergröße 
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beträgt 153600 Bytes. Ein Viertel davon sind 38400 Bytes, die bei acht Farbebenen und 16 
Bytes pro Zeichen Platz für nur 300 Zeichen bieten. Daher ist man in GEM 3.0 dazu übergegan¬ 
gen, gleich die Hälfte einer Bildspeicherlänge zu reservieren. Das funktioniert zwar, ist jedoch 
eine immense Speicherplatzverschwendung (bei einer Farbgrafikkarte mit 1024 * 768 Punk¬ 
ten in 256 Farben: über 390 KByte Puffer!). Hier sollte Atari also künftig eine flexiblere For¬ 
mel (wie die oben vorgeschlagene) einsetzen. 


Startupcode für Accessories 

Aecessories werden zwar wie echte GEMDOS-Prozesse geladen, damit hört die Ähnlichkeit 
aber schon auf. Die vom “Pexec()”- Aufruf angelegte Basepage ist nicht vollständig ausgefüllt, 
und anders als bei einem normalen GEMDOS-Programm wird beim Aufruf der Basepage- 
Zeiger nicht auf dem Stack, sondern in Adreßregister A0 übergeben. Darüber hinaus muß 
unbedingt ein eigener Stack angelegt werden, da der Stackpointer beim Aufruf normalerweise 
auf Null initialisiert ist (genaugenommen wird er mit einem zufälligen Wert initialisiert, der 
eben praktisch immer Null ist). Zusammenfassung: 

- Wenn bei Programmstart A0 den Wert Null hat, dann handelt es sich um einen normalen 
Programmstart (wie im GEMDOS-Kapitel beschrieben). 

- Anderenfalls handelt es sich um ein Accessory, und A0 enthält einen Zeiger auf die 
unvollständig ausgefüllte Basepage. Die TPA ist bereits passend geschrumpft (auf die 
Summe von Basepagegröße und der Längen der drei Programmsegmente). Ein Stack 
muß erst noch angelegt werden. 

Mit diesen Informationen ist es kein Problem, den Startup-Code für ein Programm so zu 
gestalten, daß er selbständig erkennt, wie das Programm gestartet worden ist, und entspre¬ 
chend die Initialisierung fortsetzt. Bei den meisten neueren C-Compilem wird im Startupcode 
automatisch die externe Variable “_app” initialisiert, die genau dann gleich Null ist, wenn das 
Programm als Accessory gestartet worden ist. Damit kann man Programme so entwickeln, daß 
sie sowohl als Accessory als auch als normales Programm eingesetzt werden können. 


Die Applikations-Bibliothek 

Dieser Teil der AES beschäftigt sich mit allem, was mit der Installation und Abmeldung von 
Applikationen und der Kommunikation zwischen Applikationen zu tun hat. 

Dies ist wegen der - wenn auch eingeschränkten - Multitasking-Fähigkeiten von GEM 
dringend nötig. Jede GEM-Applikation sollte sich mit “appl_init()” ordnungsgemäß anmel- 
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den. Dabei erhält sie eine eindeutige Kennung, meist als “ap_id” bezeichnet, die sie von allen 
anderen, gleichzeitig im Speicher befindlichen GEM-Prozessen unterscheidet. Daneben wird 
das GLOBAL-Feld (siehe auch unter Parameterübergabe) initialisiert, das wie folgt aussieht: 


WORD gIobal[15]; 

global[0] (ap_version): 

global| 1] (ap_count): 

globai[2) (ap_id): 
global[3,4] (ap_pprivate): 

global[5,6] (ap_ptree): 

global[7,8] (ap_pmem): 

global[9] (ap_lmem): 

global[10] (ap_nplanes): 

global( 11,12]: 
global [13] (ap_bvdisk): 

global[14] (ap_bvhard): 


Hier steht die AES-Versionsnummer. Zur Zeit mögliche Werte 
für Atari-GEM sind 0x0100 (GEM 1.0), 0x0120 (GEM 1.2), 
0x0140 (GEM 1.4) und 0x0300 (GEM 3.0). 

Maximalzahl von gleichzeitig unterstützten Applikationen (wird 
von den AES eingetragen) und ist zur Zeit “1 ”, 

Kennung der Applikation (wird von den AES eingetragen). 
Irgendwelche Informationen, die nur für die Applikation von 
Bedeutung sind und auch von ihr gesetzt und gelesen werden. 
Unter PC-GEM: “ob_spec” von Fenster 0 (kann benutzt werden, 
um Standardhintergrundfarbe und -muster abzufragen). 

Zeiger auf eine Liste von Zeigern auf die Objektbäume der 
Applikation. Sollte zunächst auf 0 initialisiert werden und wird 
dann von “rsrc_load()” gesetzt. 

Anfangsadresse des für die Resource-Datei reservierten Spei¬ 
chers (nicht von Atari, wohl aber von Digital Research doku¬ 
mentiert). 

Länge des reservierten Speichers (nicht von Atari, wohl aber von 
Digital Research dokumentiert). 

Anzahl der Farbebenen (nicht von Atari, wohl aber von Digital 
Research dokumentiert). 

Reserviert. 

Im PC-GEM ab Version 2.0: Bitvektor mit den auf dem Desktop 
angemeldeten Laufwerken (Bit 15: “A” etc). Im Atari-GEM: 
reserviert. 

Im PC-GEM ab Version 2.0: Bitvektor, der angibt, welche der in 
“ap_bvdisk” angegebenen Laufwerke als Festplatte betrachtet 
werden sollen. Im Atari-GEM: reserviert. 


Die Ereignis-Bibliothek 

Einleitung 

Bevor wir auf die verschiedenen Typen von Ereignissen eingehen, soll hier noch einmal auf 
die entscheidende Bedeutung dieser Funktionen für das Multitasking unter GEM eingegangen 
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werden. Der Grundgedanke ist, daß Programme, die auf irgendein Ereignis warten, dies nicht 
dadurch realisieren, daß sie in einer großen Schleife alle möglichen Ereignisse durchchecken, 
sondern indem sie den AES mitteilen, worauf sie warten und sich dann vorläufig zur Ruhe 
begeben. In dieser Wartezeit können die AES die gesamte Prozessorzeit anderen Prozessen 
zuweisen. Die Applikation wird wieder aktiviert, wenn das erwartete Ereignis dann eingetre¬ 
ten ist. 


Arten von Ereignissen (events) 


Tastatur-Ereignis: Es wird ein Tastendruck des Benutzers erwartet. 

Mausknopf-Ereignis: Es wird auf einen auszuwählenden Zustand der Maustasten ge¬ 

wartet. 


Maus-Ereignis: Es wird darauf gewartet, daß der Mauszeiger einen rechteckigen 

Teil des Bildschirms betritt oder verläßt. 


Mitteilungs-Ereignis: Die Applikation wartet auf eine Nachricht von einem anderen 

Prozeß (im allgemeinen dem Screen Manager, der das Anklicken 
von Menüs oder Veränderungen der Fenster mitteilt). 

Timer-Ereignis: Es wird auf das Verstreichen einer bestimmten Zeitspanne ge¬ 

wartet (auf gar keinen Fall statt dessen eine handgestrickte War¬ 
teschleife benutzen). 


Zusätzlich kann man auf eine beliebige Kombination solcher Ereignisse warten (Multi-Ereig¬ 
nis). 


Mitteilungs-Ereignisse 

Mitteilungs-Ereignisse dienen zur Kommunikation zwischen verschiedenen AES-Prozessen. 
In den allermeisten Fällen handelt es sich um Nachrichten, die der Screen Manager an ein 
Accessory oder die Hauptapplikation schickt. Die AES verschicken Mitteilungen in Paketen 
zu je 16 Bytes, deren Format so aussieht: 

WORD mbuf[8]; 

mbuf[0]: Nachrichtennummer 

mbuf[ 1 ]: Nummer (ap_id) des Absenders 
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mbuf[2]: Anzahl der Bytes, die noch nachträglich per “appl_read()” gelesen werden 

müssen. 

Dies ist allerdings nur eine Konvention, die eigentlich nirgendwo erzwungen wird. Nur bei 
Redraw-Aufforderungen (die anhand der Nachrichtennummer erkannt werden) nehmen sich 
die AES die Freiheit, mehrere Mitteilungen zu einer einzigen zu sammeln. 

“mbuf[2j” ist zur Zeit bei allen vom Screen Manager verschickten Mitteilungen Null (da sie 
immer nur 16 Bytes umfassen). 

Laut Digital Research sollte man also ungefähr so Vorgehen: 
evnt__mesag (rribuf); 

if (rribuf [2] > 0) 

{ 

appl_read (ap_id, rribuf[2], puffer); 

1 

Mitteilungen mit unbekannten Nachrichtennummem müssen ignoriert werden. Schließlich 
könnte der Screen Manager eines Tages erweitert werden oder mal eine benutzerdefinierte 
Mitteilung eines anderen Programms eintreffen. 

Für die einzelnen Ereignistypen hat der Rest des Nachrichtenpuffers jeweils unterschiedliche 
Bedeutungen: 

MN SELECTED (10) 

Ein Eintrag in einem Drop-Down-Menü ist angeklickt worden: 

rribuf[3]: Objektnummer des Menütitels 

mbuf[4J: Objektnummer des Menüeintrags 

WM REDRAW (20) 

Ein Teil des Arbeitsbereiches eines Fensters muß neu gezeichnet werden: 

mbuf[3]: Kennung des wiederherzustellenden Fensters 

mbuf[4]: X-Koordinate des wiederherzustellenden Fensterausschnitts 

mbuf[5]: Y-Koordinate des wiederherzustellenden Fensterausschnitts 

mbuf[6]: Breite des wiederherzustellenden Fensterausschnitts 

mbuf[7]: Höhe des wiederherzustellenden Fensterausschnitts 
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Bemerkungen 

Mehrere aufeinanderfolgende “WM_REDRAW”-Mitteilungen werden von den AES zu einer 
einzigen Mitteilung zusammengefaßt. 


WM TOPPED (21) 

Dieses Fenster wird zum aktuellen Fenster. 
mbuf[3]: Kennung des Fensters 

WM CLOSED (22) 

Das Schließfeld des Fensters ist angeklickt worden. 
mbuf[3]: Kennung des Fensters 

WMFULLED (23) 

Die Full-Box (volle Bildschirmgröße) des Fensters ist angeklickt worden. 
mbuf[3]: Kennung des Fensters 


WMARROWED (24) 

Einer der Pfeile ist angeklickt worden. 


mbuf[3]: 

mbuf[4]: 


Kennung des Fensters 

Art der geforderten Veränderung: 

WA„UPPAGE (0): Seiteaufwärts(BalkenoberhalbdesSchiebersangeklickt) 
Seite abwärts (Balken unterhalb des Schiebers angeklickt) 
Zeile aufwärts (Pfeil nach oben angeklickt) 

Zeile abwärts (Pfeil nach unten angeklickt) 

Seite links (Balken links des Schiebers angeklickt) 
Seite rechts (Balken rechts des Schiebers angeklickt) 
Spalte links (Pfeil nach links angeklickt) 

Spalte rechts (Pfeil nach rechts angeklickt) 


WA_DNPAGE (1): 
WAJJPLINE (2): 
WA_DNLINE (3): 
WAJJFPAGE (4): 
WA_RTPAGE (5): 
WAJJFLINE (6): 
WA_RTLINE (7): 


WMHSLID (25) 

Der horizontale Schieber eines Fensters wurde bewegt. 

mbuf[3]: Kennung des Fensters 

mbuf[4]; von 0 (ganz links) bis 1000 (ganz rechts) 
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WMVSLID (26) 

Der vertikale Schieber eines Fensters wurde bewegt. 

mbuf[3]: Kennung des Fensters 

mbuf[4]: von 0 (ganz oben) bis 1000 (ganz unten) 

WMSIZED (27) 

Die Größe eines Fensters wurde geändert (dabei sind die Außenmaße gemeint). 

mbuf[3]: Kennung des Fensters 

mbuf[4]: X-Koordinate 

mbuf[5]: Y-Koordinate 

mbuf[6]: neue Breite 

mbuf[7]: neue Höhe 

WM MOVED (28) 

Die Position eines Fensters wurde geändert (wiederum Angabe der Außenmaße). 

mbuf[3]: Kennung des Fensters 

mbuf[4]: Neue X-Koordinate 

mbuf[5]: Neue Y-Koordinate 

mbuf[6]: Breite (sollte gleichgeblieben sein) 

mbuf[7]: Höhe (sollte gleichgeblieben sein) 

WM NEWTOP (29) 

Diese Mitteilung hatte wohl eine ähnliche Funktion wie “WM_TOPPED”, ist aber mittlerwei¬ 
le nicht mehr dokumentiert und scheint auch nicht aufzutreten. 

WMJJNTOPPED (30) - nur in PC-GEM ab Version 2.0 

Das betreffende Fenster wird gerade inaktiv. Diese Nachricht kann man benutzen, um vorher 
den Fensterinhalt irgendwo zu sichern! 

mbuf(3]: Kennung des Fensters 


AC_OPEN (40) 

Der Eintrag des Accessories im ersten Drop-Down-Menü wurde angeklickt. 
mbuf[4]: Kennung (menu_id) des Menü-Eintrags 
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Bemerkungen 

Dies scheint ein echter Fehler im Atari-GEM zu sein, da in sämtlichen PC-Dokumentationen 
mbuf[3] angegeben wird - es bietet sich an, diese Information gänzlich zu ignorieren, da man 
die AC_OPEN-Nachricht sowieso nur für das eigene Accessory empfängt. Mehr als einen 
Menüeintrag (wie die erste Version des Kontrollfeld-Accessories) sollte man aus Rücksicht 
auf andere Accessories sowieso nicht verwenden. 

ACCLOSE (41) 

Ein Accessory wurde geschlossen. Damit ist der Start oder das Ende einer Haupt-Applikation 
gemeint. Das Accessory braucht seine Fenster nicht selbst zu schließen! 

mbuf[3]: Kennung (menujd) des Menü-Eintrags 

Bemerkungen 

Erst ab Atari-GEM 3.0 darf man sicher sein, daß diese Mitteilung tatsächlich vor dem 
endgültigen Ende (also dem Verlust von Speicherblöcken und Dateikennungen) des 
Hauptprogramms eintrifft. 

CTJUPDATE (50), CT MOVE (51), CT_NEWTOP (52) 

Von Digital Research so angegeben; Funktion unbekannt. 

CTJKEY (53) 

Diese Mitteilungsnummer wird von dem modularen Kontrollfeld “XCONTROL” zur Mel¬ 
dung von Tasteneingaben benutzt (Genaueres dazu bei der Dokumentation von “XCON¬ 
TROL”). 


Benutzerdefinierte Mitteilungen 

Neben den vordefinierten Mitteilungen kann man natürlich auch noch selbst definierte 
Nachrichten einsetzen - zum Beispiel, um ein Accessory und ein Hauptprogramm miteinan¬ 
derkommunizieren zu lassen. Digital Research schlägtfür solche Nachrichten Mitteilungsnum- 
mem jenseits von 1024 vor. 

Mittlerweile sind viele flexible Protokolle auf Basis der AES-Events festgelegt worden. 
Exemplarisch sei das “AV-Protokoll” genannt, das im alternativen Desktop “Gemini” für die 
Kommunikation zwischen Desktop und Accessories zuständig ist und auch leicht auf andere 
Programme angewandt werden kann. Einige nützliche Eigenschaften: 
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- Accessory-Fenster können in die Fensterverwaltung des Hauptprogramms aufgenom¬ 
men werden (zum Beispiel für “Fenster wechseln”). 

- Accessories können Tastendrücke an das Hauptprogramm weiterleiten. 

- Accessories können Statusinformationen durch das Hauptprogramm laden und sichern 
lassen. 

- Accessories werden darüber informiert, wenn ein Bildsymbol in das Fenster des 
Accessories gezogen wurde. 

- Accessories können Gemini-Fenster öffnen und Programme starten lassen. 

Wie man sieht, bietet das “AV-ProtokoU” allerlei nützliche Dinge. Eine vollständige 
Dokumentation finden Sie in der Gemini-Dokumentation. 


Die Menü-Bibliothek 

Zu den Grundlagen der Drop-Down-Menüs braucht nicht viel gesagt zu werden - jeder kennt 
sie aus Desktop und vielen Anwendungsprogrammen. 

Anders steht es mit vielen Details: Welche Standardmenüs sollte es geben, wie zeigt man 
Tastatur-Shortcuts an? Die Antworten zu diesen Fragen finden Sie im Kapitel “Richtlinien zur 
Benutzerführung und Programmierung”. 

Die aktuellen AES-Versionen auf dem Atari erlauben nur eine Menüleiste - Accessories 
müssen also andere Wege derBenutzerführung gehen. Beim PC-GEM werden die Menüleisten 
automatisch umgeschaltet: je nachdem, welchem AES -Prozeß das aktive Fenster gehört. Man 
darf wohl davon ausgehen, daß es unter einem künftigen, multitaskingfähigen AES genauso 
funktionieren wird. 

Noch eine Bemerkung zur Namensgebung: Drop-Down-Menüs sind etwas anderes als die 
“Pull-Down”-Menüs, wie sie zum Beispiel auf dem Macintosh benutzt werden. Erste “fallen 
herunter”, wenn man sie mit dem Mauszeiger berührt. “Pull-Down”-Menüs hingegen werden 
erst ausgeklappt, wenn man mit gedrückter Maustaste in den Menübereich fährt. 

“Drop-Down"-Menüs haben den Nachteil, daß man sie oft unabsichtlich aktiviert und erst 
durch einen Mausklick wieder los wird. Mac-artige Menüs hingegen sind meist für Anfänger 
schwerer zu bedienen, weil sie die Koordination von Maustaste und Mausbewegung erfordern. 
Ab PC-GEM Version 3 kann man das Verhalten der Menüs mittels “menu_click(>” einstellen. 
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Wenden wir uns nun der interessanten Frage zu, was denn so ein Menü-Objektbaum (den man 
mit “menu_bar()” auf den Bildschirm bringt) eigentlich ist. Dazu schauen wir uns einmal die 
Objektstruktur an, die ein Resource-Construction-Programm erzeugt, wenn man eine MENÜ- 
Struktur entwirft. 

Der Objektbaum besteht aus insgesamt 17 Objekten (nähere Informationen zu Objekten 
übrigens im Kapitel über die Objekt-Bibliotheken...): 

Objekt 0: Äußere Box (IBOX), die den gesamten Baum umfaßt 

Objekt 1: Unsichtbare Box für den Menü-Balken (enthält Objekt 2) 

Objekt 2: Solide weiße Box, die alle Menü-Titel umfaßt (enthält Objekt 3 und 4) 

Objekt 3: Titel “Desk” 

Objekt 4: Titel “File” 

Objekt 5: Unsichtbare Box, liegt genau unterhalb des Menü-Balkens (enthält Objekte 6 

und 15) 

Objekt 6: Box für das Desk-Menü (enthält als Objekte die einzelnen Einträge 7-14) 

Objekt 7: Eintrag “Your message here...” 

Objekt 8: Eintrag “-” 

Object 9; Einbag “Desk Accessory 1 “ 

Object 10: Einbag “Desk Accessory 2 “ 

Object 11: Einbag “Desk Accessory 3 “ 

Object 12: Einbag “Desk Accessory 4 “ 

Object 13: Einbag “Desk Accessory 5 “ 

Object 14: Einbag “Desk Accessory 6 “ 

Objekt 15: Box für das File-Menü (enthält Objekt 16) 

Objekt 16: Einbag “Quit “ 
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Schließlich noch ein Hinweis auf künftige Weiterentwicklungsmöglichkeiten: Wann immer 
möglich, sollte man die Funktionen der Menü-Bibliothek benutzen, anstatt direkt auf die 
Objekte zuzugreifen. Die momentan benutzte Struktur schränkt die Anzahl der Accessory- 
Einträge auf sechs ein, so daß unter Umständen eines Tages eine Umstellung der internen 
Repräsentation der Menüs vorgenommen werden könnte. 


Die Objekt-Bibliothek 

Das Konzept 

Objekte sind das grundlegende Element der AES. Dateiauswahlbox, Alarmboxen, Fenster, 
Drop-Down-Menüs - alles ist intern aus Objekten zusammengesetzt. 

Ein “object” ist nichts anderes als eine Datenstruktur, die ein grafisches Objekt (wie eine Box, 
einen Text oder einen Knopf) beschreibt. Dazu gehören in erster Linie Typ (Knopf, Text¬ 
eingabefeld...), Position und verschiedene Attribute (zum Beispiel das Füllmuster eines Box- 
Objekts). 

Die einzelnen Objekte sind in einer visuellen Hierarchie geordnet. Mit Hierarchie ist in diesem 
Zusammenhang gemeint, daß zu jedem Objekt genau ein übergeordnetes Parent -Objekt 
gehört (außer es handelt sich bereits um das höchste Objekt). “Visuell” steht dafür, daß sich 
die Hierarchie nicht nur in der Datenstruktur, sondern auch in der Repräsentation auf dem 
Bildschirm wiederspiegelt. 

So ist in einer einfachen Alarmbox jedes Objekt (also Texte, Knöpfe und das Bildsymbol) ein 
Child -Objekt der Hintergrundbox. Dieses nennt man oft auch das Wurzelobjekt. Die Hierar¬ 
chieebenen können natürlich auch noch weitergehen. Oft sieht man mehrere Knöpfe, die 
gemeinsam in einem umgebenden Rahmen zusammengefaßt sind. 

Vom Modell des objekt-orientierten Programmierens kennt man die Idee, daß ein Parent- 
Objekt an die ihm untergeordneten Objekte Eigenschaften vererbt. Bei den AES-Objekten 
handelt es sich freilich nur um den Bezugspunkt der Positionsangabe. Diese ist also immer als 
Offset zur Position des übergeordneten Objekts zu verstehen. Nur beim Wurzelobjekt handelt 
es sich um eine absolute Bildschirmposition. 

Jedes Objekt bedeckt ein genau definiertes Rechteck (dessen Breite und Höhe in der 
Objektstruktur angegeben ist). Sinn und Zweck der visuellen Hierarchie ist, daß für jedes 
Objekt das zugehörige Rechteck vollständig in dem des Parent-Objekts enthalten ist. Die 
meisten Resource-Construction-Programme fördern diese Gliederung, indem sie vor Überlap- 
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pungen warnen. Zur Veranschaulichung wollen wir hier den Algorithmus darstellen, den 
“objc„offset()” benutzt, um die absolute Bildschirmposition eines Objekts zu ermitteln: 

WORD 

objc_offset (OBJECT *Tree, WORD ObNum, WORD *Xoff, WORD *Yoff) 

{ 

WORD sumx = 0, sumy = 0; /* Auf 0 initialisieren */ 

do 

{ 

sumx += Tree[ObNum],ob_x; /* Position aufaddieren */ 
sumy += Tree[ObNum].ob_y; 

ObNum = objc_get_parent (Tree, ObNum); 

} while (ObNum != -1); /* -1: Wurzel erreicht */ 

*Xoff = sumx; 

*Yoff = sumy; 

return TRUE; 

} 

Es werden also die X- und Y-Positionen des betreffenden Objekts und aller übergeordneter 
Objekte aufsummiert. 

Auch “objc_draw0” macht sich die Gliederung eines Objektbaums zunutze. Es beginnt bei 
dem Wurzelobjekt und steigt dann rekursiv immer tiefer die Objekthierarchie hinunter. Folge 
ist der allseits bekannte Effekt, daß die Objekte der untersten Ebene zuletzt und damit 
“zuoberst” gezeichnet werden. 

Eine besonders aufwendige und zeitkritische Aufgabe ist es, das oberste, an einer bestimmten 
Bildschirmkoordinate liegende Objekt zu finden. Dieses Problem müssen die AES bei jedem 
einzelnen Mausklick in eine Dialogbox bearbeiten. 

Die hierarchische Gliederung macht es einfach: Ein Unterbaum eines Objekts braucht nur 
dann untersucht zu werden, wenn die Koordinaten innerhalb des Rechtecks des Parent-Objekts 
liegen. Auf diese Weise werden die Suchzeiten drastisch reduziert (für Mathematiker: von 
O(n) auf 0(log n)). 

Wenn man jetzt noch weiß, daß die Fenster intern als Objektbaum dargestellt werden und ein 
Aufruf von “wind_find()” ziemlich direkt zu einem Aufruf von “objc_find(>” führt, wird 
dieses Objekt-Modell wohl auch recht einleuchtend erscheinen. 
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Die Implementation 

Baumartige Datenstrukturen sind zwar sehr flexibel, dafür aber im Vergleich zu einfachen 
Feldern etwas schwerfällig. Auf modernen Workstations würde man vielleicht tatsächlich 
einen “echten” Baum benutzen. 1984 galt es jedoch, möglichst wenig Platz zu verbrauchen 
und so effizient wie nur möglich zu sein. 

Objektbäume werden deshalb als Felder (Arrays) von einzelnen Objektstrukturen dargestellt. 
Dadurch kann bei Kenntnis der Adresse des W urzelobjekts direkt auf jedes Objekt des Baums 
zugegriffen werden, ohne erst lang verzeigerte Strukturen durchlaufen zu müssen. Die 
Verkettung der einzelnen Objekte erfolgt nicht über echte Zeiger, sondern jeweils über deren 
Nummer im Feld. Nachteil dieses Konzepts ist, daß bestehende Bäume nur durch Umkopieren 
vergrößert werden können. Die Gliederung erfolgt über die drei speziellen Einträge in der 
Objekt-Struktur: 

ob_next: Nummer des folgenden Objekts gleicher Ebene oder - falls es das letzte Ele¬ 

ment in der Ebene ist - des Parent-Objekts. 

ob_head: Nummer des ersten Kinds des Objekts. 

ob_tail: Nummer des letzten Kinds des Objekts. 

Zeiger, die nirgendwohin weisen (zum Beispiel, weil es keine tiefere Ebene mehr gibt), haben 
den Wert “-1” (gemeinhin NIL genannt). 

Bevor wir uns nun in alle Spielarten von Objekten vertiefen, sei darauf verwiesen, daß man 
Objektbäume (im Atari-Jargon auch gerne Resources genannt) üblicherweise nicht “zu Fuß” 
im Speicher zusammensetzt (das geht natürlich auch), sondern mit einem “Resource 
Construction Set” (RCS) entwirft und in einer Resource-Datei ablegt, die das Programm dann 
mittels “rsrc_load()” lädt. Ein sehr leistungsfähiges RCS ist das Programm “Interface”, das 
von der Firma Shifit vertrieben wird. 


Die Objekt-Struktur 

Ein Objekt hat folgende Struktur: 


typedef struct 
{ 

WORD ob_next ; 
WORD ob__head; 
WORD ob tail; 


/* Nummer des nächsten Objekts */ 
/* Nummer des ersten Kinds */ 

/* Nummer des letzten Kinds */ 
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UWORD 

ob_type; 

/* 

Art des Objekts */ 

UWORD 

ob_flags; 

/* 

Verschiedene Flags */ 

UWORD 

ob_state; 

/* 

Status des Objekts */ 

void 

*ob__spec; 

/* 

typabhängig */ 

WORD 

°b_x; 

/* 

X-Position (rel, zum Parent- 
Objekt) */ 

WORD 

ob_y; 

/* 

Y-Position (rel. zum Parent- 
Objekt) */ 

WORD 

ob width; 

/* 

Breite */ 

WORD 

} OBJECT; 

ob_height; 

/* 

Höhe */ 


Das Strukturelement “ob_spec” ist 32 Bits groß. 

Seine Bedeutung hängt ganz von “ob_type” des Objekts ab. Für C-Programmierer erscheint 
daher die Deklaration einer "Union” als sinnvoll, damit man ohne die lästige Anwendung von 
“typecasts” zugreifen kann: 

/* Deklaration von "OBSPEC" als Union, angelehnt an die Definition 
im AES.H des Turbo-C-Compilers */ 

typedef union obspecptr 

{ 

LONG 

union obspecptr 
bfobspec 
TEDINFO 
ICONBLK 
BITBLK 
USEFBLK 
char 
} OBSPEC; 

Die Deklaration von “objspec” in der OBJECT-Struktur ändert sich dadurch zu: 

OBSPEC ob_spec; 

Zum Zugriff auf eine TEDINFO-Struktur würde man also 
Tree[ob].ob_spec.tedinfo 


Index; 

*indirect; 

obspec; /* siehe unten */ 

*tedinfo; 

*iconblk; 

*bitblk; 

*userblk; 

*free_string; 


anstelle von 
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(TEDINFO *)Tree[ob] .ob_spec 

schreiben. Ähnliche Deklarationen sind auch in Pascal oder in Modula-2 denkbar. 

Zu besprechen bleiben also noch die Strukturelemente “ob.type”, “ob_flags”, “ob_state” und 

“ob_spec”: 


Objekttypen (ob type) 

Das obere Byte des Objekttyps w ird von den AES komplett ignoriert und steht daher für eigene 
Anwendungen zu r Verfügung (speziell alsZusatzinformation für selbstdefinierte Objekttypen, 
wie man sie mittels der USERDEF-Struktur erzeugen kann). 

Wenn man in eigenen Programmen Entscheidungen anhand des Objekttyps fällt, sollte man 
also immer die obersten acht Bits ausmaskieren! 


GJBOX (20) 


G_TEXT (21) 

G BOXTEXT (22) 


Rechteckiger Kasten mit diversen Attributen. “ob_spec” enthält 
verschiedene Informationen über Rahmenstärke, Farbe und 
ähnliches. 

Grafik-Text. “ob_spec” zeigt auf eine TEDINFO-Struktur. 

Rechteckiger Kasten mit Grafik-Text. “ob_spec” zeigt auf eine 
TEDINFO-Struktur. 


GJMAGE (23) 
G_USERDEF (24) 


GJBOX (25) 


GJ3UTTON (26) 


Ein einfaches Bild. “ob_spec” zeigt auf eine BITBLK-Struktur. 

Dieser Objekttyp erlaubt es, eigene Funktionen zur Ausgabe zu 
definieren. Die AES kümmern sich dabei auf Wunsch um die 
Darstellung der verschiedenen Objektzustände (siehe “ob_state”). 
“ob_spec” zeigt auf eine USERBLK-Struktur, die insbesondere 
einen Zeiger auf eine Ausgabefunktion enthält. Dieser Objekttyp 
wurde ursprünglich als “G_PROGDEF” bezeichnet. 

Unsichtbares Rechteck (ohne Inneres). Nur wenn die Umrandung 
nicht die Dicke Null hat, kann man es sehen. “ob_spec” enthält 
weitere Informationen über das Aussehen. 

Zentrierter Text in einem Rechteck. “ob_spec” zeigt auf eine 
Zeichenkette mit dem Text, der in dem Knopf erscheinen soll. 
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GJBOXCHAR (27) 


G_STRING (28) 
G_FTEXT (29) 


Rechteck, das einen einzigen Buchstaben enthält. In “ob_spec” 
wird nicht nur das Aussehen der Umrandung, sondern auch das 
Zeichen definiert (Detail am Rande: Die “Eckelemente” der 
AES-Fenster werden intern mit diesem Objekttyp erzeugt). 

Zeichenkette. “ob_spec” zeigt auf den entsprechenden String im 
Speicher. 

Formatierter Grafik-Text. “ob_spec” zeigt auf eine TEDINFO- 
Struktur. 


G_FBOXTEXT (30) Rechteck mit formatiertem Grafik-Text. “ob_spec” zeigt auf 

eine TEDINFO-Struktur. 


GJCON (31) Icon. “ob_spec” zeigt auf eine ICONBLK-Struktur. 

G_TITLE (32) Titel eines Drop-Down-Menüs.“ob_spec”zeigtauf eineZeichen- 

kette im Speicher. 


Viele Bits im “ob spec” 

Für G_BOX, GJBOX und G_BOXCHAR zeigt “ob_spec” nicht auf eine andere Datenstruktur, 

sondern enthält weitere Informationen zum Aussehen des Objekts: 

Bit 24..31: Darzustellendes Zeichen (nur bei G_BOXCHAR, ansonsten unbenutzt) 

Bit 16..23: 0: Rahmendicke 0 (kein Rahmen) 

l bis 128: Der Rand liegt 1 bis 128 Pixel im Inneren des Objekts 
-1 bis -127: Der Rand liegt 1 bis 127 Pixel außerhalb des Objekts 

Bit 12..15: Rahmenfarbe (0..15) 

Bit 8..11: Textfarbe (0.. 15) 

Bit 7: Text transparent (0) oder deckend (1) 

Bit 4..6: IP_HOLLOW (0): hohl 

IP_1PATT (1): ansteigende Intensität 
IP_2PATT (2) 

EP_3PATT (3) 
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IP_4PATT (4) 

IP_5PATT (5) 

IP_6PATT (6) 

IP_SOLID (7): solide Fläche 
Bit0..3: Innenfarbe (0.. 15) 

Zum vereinfachten Zugriff bietet sich die Definition eines C-Bitfelds an (Voraussetzung ist 
dabei allerdings, daß der verwendete C-Compiler die Bits in der gleichen “Richtung” anordnet 
wie das hier benutzte Turbo-C): 


typedef struct 

{ 

unsigned character : 8; 

signed framesize : 8; 

unsigned framecol : 4; 

unsigned textcol : 4; 

unsigned textmode : 1; 

unsigned fillpattern : 3; 

unsigned interiorcol : 4; 

} bfobspec; 


Vorteil : Zum Zugriff auf einzelne Teile des Bitfelds kann man einfach den Namen des Feld¬ 
elements angeben - ein aufwendiges Shiften und Ausmaskieren von Bits entfällt. Beispiel : Die 
Textfarbe erhält man mit: 

Tree[ob].ob_spec.obspec.textcol 


Objekt-Flags (obflags) 

Für jedes Flag wird ein Bit in “ob_flags” benutzt. Außerdem ist meist noch die Konstante 

“NONE” (für keine Flags, also 0) vordefiniert. 

SELECTABLE (0x0001) Der Benutzer kann das Objekt durch Anklicken selektieren. 

DEFAULT (0x0002) Hebt normalerweise das Objekt optisch hervor und bedeutet, daß 

das Drücken von RETURN mit dem Anklicken dieses Objekts 
gleichgesetzt wird (bei Aufruf von “form_do()”). Innerhalb 
eines Dialoges sollte man nur bei einem Objekt DEFAULT 
setzen. 
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exit (0x0004) 

“form_do()” bricht ab, wenn der Benutzer das Objekt anklickt. 
Man beachte, daß die AES unter " Anklicken” das Niederdrücken 
und Loslassen einer Maustaste verstehen! 

EDITABLE (0x0008) 

Das Objekt ist editierbar. 

RBUTTON (0x0010) 

Das Objekt ist ein sogenannter Radioknopf (radio button). Dies 
ist eine Metapher aus der Zeit der Rundfunkgeräte, als bei 
Anwahl einer Station jeweils die anderen Tasten wieder heraus¬ 
sprangen. Auf die AES übertragen bedeutet dies, daß von allen 
Objekten, bei denen dieses Flag gesetzt ist und die in der gleichen 
Hierarchieebene des Objektbaums stehen, nur eines ausgewählt 
sein kann. Wird ein anderes angeklickt, werden alle anderen 
automatisch deselektiert. 

LASTÖB (0x0020) 

Letztes Objekt im Objektbaum-Feld. Wird zumindest bei 
“form_do()” beim Durchsuchen des Baums nach DEFAULT- 
und EDIT-Objekten benötigt. 

TOUCHEXIT (0x0040) 

Diese Bezeichnung ist ein wenig verwirrend und sollte besser 
“CLICKEXrr” lauten. Wird bei “form_do()” ein solches Objekt 
mit gedrückter Maustaste berührt (die Maustaste muß also nicht 
erst wieder losgelassen werden), bricht die Funktion ab (und 
liefert die Objektnummer des berührten Objekts). 

HIDETREE (0x0080) 

Versteckt Objekt und alle Unterobjekte. Das Objekt wird also 
nicht nur nicht gezeichnet, sondern ist auch logisch nicht vorhan¬ 
den (wichtig für “objc_find()”!). Editierbare Objekte kann man 
übrigens auch ausfüllen, wenn sie versteckt sind... (prima für 
Passwordeingaben...) 

INDIRECT (0x0100) 

Zeigt an, daß in “ob_spec” ein Zeiger auf den eigentlichen 
“ob_spec” steht. 

Alle weiteren Bits sind reserviert und sollten laut Digital Research auf Null gesetzt werden. 

Objekt-Status (ob state) 

Während die “ob_flags” in erster Linie Informationen über die Funktion eines Objekts 
enthalten, beschreibt der Objekt-Status den Zustand des Objekts (oft ist auch die Konstante 
NORMAL (0) als “Normalzustand” vordefiniert). 
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SELECTED (0x0001) Das Objekt wird hervorgehoben, indem es invertiert dargestellt 

wird. Dieses Bit ist übrigens immer bei dem Objekt gesetzt, das 
das Verlassen eines Dialoges verursacht hat, und sollte deshalb 
beizeiten wieder gelöscht werden. 

CROSSED (0x0002) Im Inneren des Objekts (nur für BOX-Objekte) wird ein Kreuz 

gezeichnet. 

CHECKED (0x0004) Das Objekt wird mit einem Häkchen gezeichnet (wird beispiels¬ 

weise bei Einträgen in Drop-Down-Menüs verwendet). 

DISABLED (0x0008) Das Objekt wird grau schattiert gezeichnet (normalerweise bei 

Text). Angezeigt wird damit, daß es nicht selektiert werden 


OUTLINED (0x0010) Um das Objekt wird eine zusätzliche Umrandung gezeichnet. 

SHADOWED (0x0020) Zusätzlich wird rechts unter dem Objekt ein Schatten gezeichnet 

(meistens bei BOX-Objekten). 

WHITEBAK (0x0080) Die Icon-Maske wird nicht mitgezeichnet. Kann die Ausgabe 

beispielsweise dann beschleunigen, wenn der Hintergrund so¬ 
wieso schon weiß ist (nur für PC-GEM dokumentiert!) 

DRAW3D (0x0040) Nur für ICONBLK-Strukturen und auch nur ab PC-GEM 2.0 

wird ein dreidimensionaler Effekt erzeugt, indem das Icon 
dreimal knapp schräg übereinander gezeichnet wird. 

Objektfarben 

Folgende Objektfarben sind vordefiniert (das hängt natürlich von der gewählten Bildauflösung 
und den Einstellungen des Benutzers ab): 

WHITE (0) Weiß 

BLACK (1) Schwarz 

RED (2) Rot 

GREEN (3) Grün 

BLUE (4) Blau 

CYAN (5) Cyan 

YELLOW (6) Gelb 

MAGENTA (7) Magenta 



AES-Betriebssystemroutinen 


559 


LWHITE (8) Hellgrau 

LBLACK (9) Dunkelgrau 

LRED (10) Hellrot 

LGREEN (11) Hellgrün 

LBLUE (12) Hellblau 

LCYAN (13) Hellcyan 

LYELLOW (14) Hellgelb 
LMAGENTA (15) Hellmagenta 


Die Textinformations-Struktur (TEDINFO) 

Ein TEDINFO hat folgende Struktur: 


typedef struct 
{ 

char *te_ptext; 
char *tejptmplt; 
char *te_pvalid; 
WORD te_font; 

WORD te_resvdl; 
WORD te_just; 

WORD te_color; 
WORD te_resvd2; 
WORD te_thickness; 
WORD te_txtlen; 
WORD te_tmplen; 

} TEDINFO; 


/* Zeiger auf Text */ 

/* Zeiger auf Textmaske */ 

/* Zeiger auf Texttypmaske */ 

/* Zeichensatz */ 

/* reserviert */ 

/* Justifikation */ 

/* Farbe des betreffenden Rechtecks */ 
/* reserviert */ 

/* Rahmen */ 

/* Länge des Textes */ 

/* Länge der Textmaske */ 


Diese Datenstruktur wird von allen Objekten benutzt, die die Eingabe von Text zulassen. 
Die einzelnen Strukturelemente: 


te_ptext Zeiger auf die eigentliche Zeichenkette (die durch den Editiervorgang auch 
verändert wird). Ist das erste Zeichen ein (“Schneckennudel” oder 
“Klammeraffe”), werden alle folgenden Zeichen als Platzhalter angesehen, 
und der zunächst ausgegebene Text besteht aus Leerzeichen (“@2345678” 
liefert beispielsweise einen acht Leerzeichen langen String, der Klammeraffe 
wird also mitgezählt). Folge: das Zeichen “@” kann niemals am Anfang eines 
Edit-Felds stehen! Dieser String muß genauso lang sein, wie in “te_ptmplt” 
gültige Stellen vorhanden sind. 
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te_ptmplt Dieser String enthält nicht nur den Teil der Textinformation, der immer gleich 

ist, sondern auch eine Maske für die Zeichen, die verändert werden dürfen. 
Dafür setzt man den Unterstrich ein, der allerdings beim Editieren der Texte 

mit einem RCS meist durch die Tilde ersetzt wird. 

te_pvalid String, der für jedes Zeichen in “te_ptext” eine Zeichenkonstante enthält, die 
über die Gültigkeit verschiedener Zeichen an dieser Stringposition Auskunft 
gibt: 

“9”: nur Ziffern 

“A”: nur Großbuchstaben und Leerzeichen 

“a”: nur Buchstaben und Leerzeichen 

“N”: Großbuchstaben, Ziffern und Leerzeichen 

“n”: Buchstaben, Ziffern und Leerzeichen 

“F”: alle Zeichen, die zu einem Dateinamen gehören 

“P”: alle Zeichen, die zu einem Pfadnamen gehören 

“p”: wie “P”, allerdings ohne “?” und “*” 

“X”: alle Zeichen 

Bemerkungen 

Unter TOS 1.00 führt die Eingabe eines Unterstrichs in ein nur für Ziffern zugelassenes Edit- 
Feld zu einem Programmabsturz! 

Die von “F”, “P” und “p” zugelassenen Zeichen decken sich leider nicht mit der GEMDOS- 
Definition eines legalen Datei- bzw. Pfadnamens. 

te_pfont IBM (3): normaler Zeichensatz (verschieden je nach Bildauflösung) 

SMALL (5): 6*6-Systemzeichensatz 

Bemerkungen 

Alle bekannten AES-Versionen kommen bei “objc_edit()” ausschließlich mit acht Pixel 
breiten Zeichensätzen zurecht! 

tejust TEJLEFT (0): linksbündig 

TE_RIGHT (1): rechtsbündig 

TE_CNTR (2): zentriert 

te_color Für die Farbe des begrenzenden Rechtecks sind die Bits folgendermaßen 
belegt: 


Bit 12..15: Rahmenfarbe (0..15) 

Bit 8..11: Textfarbe (0.. 15) 
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Bit 7: Text transparent (0) oder deckend (1) 

Bit 4..6: IP_HOLLOW (0); hohl 

IP_1PATT (1): ansteigende Intensität 

EPJ2PATT (2) 

IP_3PATT (3) 

IP_4PATT (4) 

IP_5PATT (5) 

IP_6PATT (6) 

IP_S0L1D (7): solide Fläche 

Bit 0..3: Innenfarbe (0..15) 

te_thickness Für den Rahmen sind folgende Werte gültig: 

0: Rahmendicke 0 (kein Rahmen) 

1 bis 128: Der Rand liegt 1 bis 128 Pixel im Inneren des Objekts, 

-1 bis -127: Der Rand liegt 1 bis 127 Pixel außerhalb des Objekts. 

Zur Erläuterung der etwas komplizierten TEDINFO-Struktur ein Beispiel: 

te_ptext: "301164" 

te_pvalid: "999999" 

te_ptmplt: "Bitte Datum angeben: . .19 " 

Zunächst fügen die AES den Inhalt von “te_ptext” in die mit Unterstrichen markierten Positio¬ 
nen von “te_ptmplt” ein: 

"Bitte Datum angeben: 30.11.1964" 

Die Einfügemarke steht zunächst hinter dem letzten Zeichen von “te_ptext”, also in diesem 
Fall am Ende der Zeichenkette. Der Benutzer kann nun neben den Zifferntasten (wegen 
“te_pvalid”) innerhalb des Textes mit BACKSPACE, DELETE, den Pfeiltasten und ESC 
(löscht die Eingabe) editieren. Nehmen wir als Eingabe “<ESC>231265” an. 

Auf dem Bildschirm sieht es dann folgendermaßen aus: 

"Bitte Datum angeben: 23.12.1965" 

Wird nun der Dialog abgebrochen, dann enthält “te_ptext” “231265” - also genau die Eingabe 
des Benutzers -, bereinigt von allen festen Zeichen. 
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Die Icon-Struktur (ICONBLK) 

Was ein Icon ist, braucht hier sicherlich nicht mehr erklärt zu werden. Wie wird es jedoch im 


Speicher dargestellt? 



typedef struct 
{ 

DWORD 




*ibj?mask; 

/* 

Zeiger auf Icon-Maske */ 

UWORD 

*ib_j>data; 

/* 

Zeiger auf Icon-Daten */ 

char 

*ibj?text; 

/* 

Zeiger auf Icon-Text */ 

UWORD 

ib char; 

/* 

Zeichen, das im Icon erscheinen 
soll, und Vorder- und Hintergrund¬ 
farbe des Icons */ 

UWORD 

ib_jtchar; 

/* 

dessen X-Position */ 

DWORD 

ib_ychar; 

/* 

dessen Y-Position */ 

UWORD 

ib_xicon; 

/* 

X-Position des Icons */ 

UWORD 

ib_yicon; 

/* 

Y-Position des Icons */ 

UWORD 

ib_wicon; 

/* 

Breite des Icons */ 

UWORD 

ib_hicon; 

/* 

Höhe des Icons */ 

WORD 

ib xtext; 

/* 

X-Position der Beschriftung */ 

WORD 

ib ytext; 

/* 

Y-Position der Beschriftung */ 

UWORD 

ib wtext; 

/* 

Textbreite in Pixel */ 

UWORD 

ib htext; 

/* 

Texthöhe in Pixel */ 

UWORD 

} ICONBLK; 

ib_resvd; 

/* 

reserviert */ 


Die einzelnen Elemente der Struktur: 

ib_pmask Ein Zeiger auf ein Feld von 16-Bit-Werten, in denen das Bit-Image der Icon- 
Maske abgelegt ist. Die Icon-Maske legt fest, an welchen Stellen das Icon 
überhaupt gezeichnet werden soll und welche Pixel “transparent” bleiben sol¬ 
len. Erzielt wird dieser Effekt dadurch, daß der Iconhintergrund zunächst mit 
den Bits der Maske “undiert” und dann mit den Icondaten “oderiert” wird. 

ib_pdata Zeiger auf das eigentliche Bild des Icons 

ipjptext Zeiger auf den Icontext 

ib_char Bit 15.. 12: Vordergrundfarbe des Icons 
Bit 11..8: Hintergrundfarbe des Icons 

Bit 7..0: Das Zeichen, das im Icon erscheinen soll (wie der Laufwerk¬ 

buchstabe in den Desktop-Icons) 
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ib_xchar, 

ib_ychar Position des Zeichens innerhalb des Icons 
ib_xicon, 

ib_yicon Position des Icons auf dem Bildschirm. Bei Icons, die sich innerhalb eines 
Objektbaumes befinden, handelt es sich um die relative Position zum Mutter¬ 
objekt. 

ib_wicon, 

ib_hicon Breite (muß ein Vielfaches von 16 sein) und Höhe des Icons 
ib_xtext, 

ib_ytext Position der Textzeile innerhalb des Icons 
ib_wtext, 

ib_htext Breite und Höhe des Icon-Textes 


ib_rcsv Unbenutzt, wird allerdings bei den meisten RCS-Programmen beim Schreiben 
in die Resourcedatei aufgenommen. 


Die Bit-Image-Struktur (BITBLK) 

Ein Bit-Image kann man immer dort benutzen, wo ein nicht anwählbares Icon stehen könnte. 
Der entscheidende Unterschied ist nämlich, daß es zu einem Bit Image keine Maske gibt. 

Die Struktur: 

typedef struct 
{ 

UWORD *bi__pdata; 

UWÖRD bi_wb; 

UWORD bi_hl; 

WORD bi_x; 

WORD bi_j/; 

WORD bi__color; 

} BITBLK; 

Die einzelnen Strukturelemente: 

bi_pdata Zeiger auf Wort-Feld, das die Bilddaten enthält (siehe unter ib_pdata) 


/* Zeiger auf Image */ 

/* Breite in Bytes */ 

/* Höhe in Pixelzeilen */ 
/* X-Position */ 

/* Y-Position */ 

/* Farbe */ 
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bi_wb Breite des Images in Bytes (muß durch 2 teilbar sein) 

bi_W Höhe des Images in Zeilen 

bi_x,bi_y Position des Images 

bi_color AES-Farbcode für das Image 

Die Application-Block-Struktur (USERBLK) 

Schon mal über “fehlende” Objektformen geärgert? Der Objekttyp “G_USERDEF” erlaubt 
die Definition beliebiger neuer Objektarten. “ob_spec” zeigt dabei auf eine USERBLK- 
Struktur: 

typedef struct 
{ 

WORD <*ub__code) (PÄRMBLK *) ; 

LONG ub_parm; 

) USERBLK; 

Dabei ist “ub_code” ein Zeiger auf eine eigene Funktion, die die Darstellung des Objekts voll 
übernimmt. Als Parameter erhält sie einen Zeiger auf eine PARMBLK-Struktur: 


/* Zeiger auf eigene Funktion */ 
/* Ein optionaler Parameter */ 


Die Parameter-Block-Struktur (PARMBLK) 

typedef struct 
{ 


OBJECT 

*pb_tree; 

/* Zeiger auf Objektbaum */ 

WORD 

pb obj; 

/* Objektnummer */ 

WORD 

pb_prevstate; /* Vorheriger Status */ 

WORD 

pb_eurrstate; /* Neuer Status */ 

WORD 

pb_x; 

/* X-Position des Objekts */ 

WORD 

pb_y; 

/* Y-Position des Objekts */ 

WORD 

pb w; 

/* Breite */ 

WORD 

pbji; 

/* Höhe */ 

WORD 

pb_xc; 

/* X-Position des Begrenzungsrechtecks */ 

WORD 

pb yc; 

/* Y-Position des Begrenzungsrechtecks */ 

WORD 

pb_wc; 

/* Breite des Begrenzungsrechtecks */ 

WORD 

pb hc; 

/* Höhe des Begrenzungsrechtecks */ 

LONG 

pb_parm; 

/* Parameter aus USERBLK */ 


} PARMBLK; 
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In dieser S truktur werden der in der USERBLK-S truktur angegebenen Funktion eine Fülle von 
Informationen über das Objekt geliefert: 


pb_tree 

pb_obj 

pb_prevstate 

pb„currstate 


Anfangsadresse des betreffenden Objektbaums 
Objektnummer des betreffenden Objekts 
Status des Objekts vor der aktuellen Änderung 

Neuer Status des Objekts (nur wenn “pb_currstate” und “pb_prevstate” 
identisch sind, muß das Objekt neu gezeichnet werden. Anderenfalls reicht 
ein “Update” des Objektstatus). 


pb_x,pb_y, 

pb_w,pb_h Position und Maße des Objekts in absoluten Bildschirmkoordinaten 
pb_xc,pb_yc, 

pb_wc,pb_hy Position und Größe des aktuellen (bei “objc„draw()” angegebenen) 
Begrenzungsrechtecks (clipping rectangle). Wenn kein Clipping einge¬ 
schaltet ist (zum Beispiel bei Objekten in Drop-Down-Menüs), dann sind 
alle Werte Null. 


pb_parm Der optionale, in der USERBLK-Struktur angegebene Parameter 


Zu beachten sind folgende Punkte: 


- Die eigene Funktion muß im Datenregister DO den AES zurückliefem, welche Aspekte 
des Objektstatus noch aktualisiert werden müssen. Damit ist es nicht unbedingt nötig, 
in der eigenen Ausgabefunktion den Code zum Invertieren des Objekts auszuprogrammie¬ 
ren. 


Im allgemeinen wird man einige Bits des Objektstatus selbst bearbeiten wollen und 
andere den AES überlassen (siehe dazu das Beispiellisting in “Richtlinien zur Benutzer¬ 
führung und Programmierung”). 

- Die Funktion erhält den PARMBLK-Zeiger auf dem Stack und muß daher unter Turbo- 

C als “cdecl” deklariert sein. 

Ein vollständiges Neuzeichnen des Objekts ist nur dann nötig, wenn “pb_prevstate” und 
“pb_currstate” gleich sind. Anderenfalls hat sich nur der Objektstatus geändert (zum 
Beispiel durch Anklicken). 
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- Die eigene Funktion wird de facto als Unterprogramm der AES ausgeführt. Daher sollte 
man in Hinsicht auf Stackbenutzung vorsichtig sein. Außerdem darf man natürlich keine 
weiteren AES-Aufrufe machen (die AES sind nicht re-entrant!). Aufrufe der VDI- 
Eingabefunktionen hingegen sind an dieser Stelle erlaubt! 

- “pb_parm” dient dazu, der eigenen Funktion weitere Informationen - wie etwa einen 
Zeiger auf einen String - mit auf den Weg zu geben (vergleichbar mit dem “ob_spec” 
in der Objekt-Struktur, der ja bei “G_USERDEF”-Objekten bereits durch den USERBLK- 
Zeiger belegt ist). 

- Man sollte sich nie zu weit von der ursprünglichen Optik von GEM entfernen. 
Abgerundete Rechtecke oder kursive Texte passen sicherlich nicht in das normale 
Erscheinungsbild einer GEM-Applikation! 


Die Formular-Bibliothek 


Einleitung 

Die AES-Formular-Bibliothek nimmt sich der Verwaltung von Dialogboxen (also der 
Computerform von Formularen) an. Sie bedient sich dabei der Objekt-Bibliothek, die für die 
Darstellung der einzelnen Objekte und die Verwaltung von Tasteneingaben in Edit-Felder 
verantwortlich zeichnet. 

Direkt zur Verwaltung der Eingaben in Dialogboxen ist “form_do()” bestimmt. ‘Torm_do” 
wiederum bedient sich dazu der Event-Funktionen (um Mausbewegungen und Tastendrücke 
zu empfangen), der Objekt-Funktionen (zum Beispiel für die Edit-Felder) sowie der Formular- 
Funktionen “form_keybd()” und “form_button()”. 

Details können Sie dem weiter unten angegebenen Quelltext von “form_do()” entnehmen. Für 
das eigentliche Zeichnen der Dialogbox ist nicht die Formular-Bibliothek, sondern 
“objc_draw()” zuständig. 

“form_dial() > ’ und “form_center()” sind spezielle Hilfsroutinen für Dialogboxen, die zur Vor- 
und Nachbereitung benutzt werden können. “form_dial()” sorgt für die “Reservierung” eines 
Bildschirmausschnitts (zur Zeit eine “leere” Operation, kann sich aber durchaus künftig 
ändern), das Zeichnen von wachsenden und schrumpfenden Rechtecken, um bei bestimmten 
Operationen mehr Feedback zu bieten, sowie die “Freigabe” des belegten Bildschirmbereichs 
(was zur Zeit Redraw-Nachrichten an die betroffenen Fenster auslöst). Mit “form_center()” 
wird die Dialogbox auf dem Arbeitsbereich des Hintergrundfensters (Fenster 0) zentriert. 
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“form_alert()” und “form_error()” schließlich sind “Frontends”, die auf möglichst einfache 
Art und Weise Alarmboxen erzeugen, diese anzeigen und auch für die Wiederherstellung des 
belegten Bildausschnitts sorgen. 

Nähere Informationen darüber, auf welche Art und Weise man Dialogboxen entwerfen und 
programmieren sollte, entnehmen Sie bitte dem Kapitel “Richtlinien zur Benutzerführung und 
Programmierung”. 


Alarm-Boxen 

Alarm-Boxen sind eine spezielle Form von Dialogen, bei denen man auf fünf Textzeilen zu 
maximal 30 Zeichen, ein vordefiniertes Bildsymbol und drei Knöpfe zu maximal zehn Zei¬ 
chen begrenzt ist. Für die Iconnummem gilt: 

0: Kein Icon 

1: Ausrufezeichen (Gefahr!) 

2: Fragezeichen (Nachfrage vor möglicherweise gefährlichen Aktionen) 

3: Stopschild (nun ist es zu spät - der Fehler ist bereits aufgetreten, und der Benutzer muß 
darüber informiert werden) 

Die Daten für eine Alarm-Box werden in einem String folgenden Formats übergeben: 

"[ >Icon-Nummer< ][ >Text< ][ >Knöpfe< ]" 

Dabei ist >Icon-Nummer< eine Zahl zwischen 0 und 3 (als ASCII-Zeichen), >Text< eine oder 
mehrere Textzeilen (voneinander durch “1” getrennt) und >Knöpfe< einer oder mehrere 
Knopfnamen (ebenso voneinander getrennt). 

Ein Beispiel: 

"[3][Die Datei 1 PBUCH.DOC konnte|nicht geschrieben werden!][ OK ] " 

Man beachte die Leerzeichen links und rechts von “OK”: Sie dienen dazu, dem Knopf eine 
sinnvolle Mindestbreite zu verpassen. 

Eine spezielle Spielart von Alarm-Boxen sind die Fehler-Boxen, die man mittels “form_error()” 
erzeugen kann. Bei ihnen ist zu beachten, daß 
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- der Parameter aus Gründen der Kompatibilität zu PC-GEM eine MS-DOS-Fehlemummer 
sein muß 

- daß die Texte per definitionem in der gleichen Landessprache wie das benutzte TOS 
erscheinen und daß 

- es nicht für alle GEMDOS-Fehlemummem einen passenden Text gibt. 

Ihr Einsatz bietet sich daher nur bei kleineren Programmen, die keiner weiteren Intemationali- 
sierung bedürfen, an. 


form_keybd() und form_button() 

Diese beiden Funktionen sind eine Sache für sich, da DR sie wissentlich oder unwissentlich 
in der ursprünglichen GEM-Dokumentation weggelassen hat. Allerdings sind sie sehr wohl 
vorhanden und funktionieren auch so, wie sie sollen. 

Um sie für das DR-Entwicklungspaket zu installieren, muß man folgendermaßen vorgehen: 
Die betreffenden Funktionen definiert man genau so, wie in der AES-Referenz angegeben. 
Zusätzlich setzt man vor den ersten Aufruf im Programm die Zeile 

ctrl_cnts[135]=3; ctrl_cnts[136]=3; ctrl_cnts[137]=1; 
ctrl_cnts[138]=2; ctrl_cnts[139]=2; ctrl_cnts[140]=1; 

Statt dessen kann man auch mit einem Debugger die entsprechende Stelle in der Datei 
“apstart.o” ändern. Bei moderneren Entwicklungssystemen sind diese Funktionen meistens 
schon vorhanden. 

Beide Funktionen werden intern von “form_do()” zur Bearbeitung von Formularen benutzt. 
Dabei kann man mit “form_button()” Mausknopf-Tastendrücke simulieren und mit 
“foim_keybd()” die Gültigkeit eines eingegebenen Zeichens an einer bestimmten Position 
eines editierbaren Textfeldes feststellen. 

Wie das genau vor sich geht, kann man am besten anhand des Quelltextes von “form_do()” 
verstehen: 

#define FMD_BACKWARD -1 
#define FMD_FORWARD -2 
fdefine FMD DEFLT -3 


#define TRUE 1 
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/* Objekt bestimmten Typs suchen */ 

WORD find_object (OBJECT *tree, WORD start_object, WORD which} 

{ 

WORD object, flag, theflag, increment; 

object = 0; 
flag = EDITABLE; 
increment = 1; 

switch (which) 

{ 

case FMD_BACKWARD: 

increment = -1; /* kein Break! */ 

case FMD_FORWARD: 

object = start_object + increment; 
break; 

case FMD_DEFLT: 

flag = DEFAULT; 
break; 

} 

while (object >= 0) 

1 

theflag = tree[object].ob_flags; 

if (theflag & flag) 
return (object); 
if (theflag & LASTOB) 

object = -1; /* Abbruch */ 

eise 

object += increment; 

) 

return start_object; 

1 

/* Cursor auf Startfeld */ 

WORD ini_field (OBJECT *tree, WORD start_field) 

{ 

if (start__field — 0) 

start__field = find_object (tree, 0, FMD_FORWARD); 
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return Start field; 


WORD form_do (OBJECT *tree, WORD start_field) 

{ 

WORD edit__object, next_object, which, cont; 

WORD idx, mx, my, mb, ks, kr, br; 

windjupdate (BEG_UPDATE); 

next_object = ini_field (tree, start_field); 
edit__object = 0; 

cont = TRUE; 

while (cont) 

{ 

/* ggfs. Cursor positionieren */ 

if ((next__object != 0) && (edit_object != next_object)) 

{ 

edit_object = next_object; 
next_object = 0; 

objc_edit (tree, edit_object, 0, &idx, ED_INIT); 

} 

/* Maus- oder Tastatur-Event erwarten */ 

which = evntjnulti (MUJCEYBD|MU_BÜTTON, 0x02, 0x01, 

0x01, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, OxOL, 

0, 0, &mx, &my, &mb, &ks, &kr, &br); 

if (which & MU_KEYBD) 

{ 

cont = form keybd (tree, edit_object, next_object, 
kr, &next__object, &kr); 

/* kr != 0 -> weiterverarbeiten! */ 

if (kr) 

objc__edit (tree, edit_object, kr, &idx, EDjCHAR); 

} 
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if (which & MU_BOTTON) 

{ 

next_object = objc_find (tree, 0, MAX_DEPTH, mx, my); 


if (next_object == -1) 

{ 

Bconout (2, 7); /* Ping! */ 

next_object = 0; 

} 


} 


eise 

cont = form_button (tree, next_object, br, 
&next_object); 


/* ggf. Cursor ausschalten */ 


if (icont || ((next_object != 0) && 

(next__object != edit__object))) 

{ 

objc_edit (tree, edit_object, 0, &idx, ED_END); 

} 

} 


wind_update (ENDJÜPDATE); 
return next_object; 


Die Grafik-Bibliothek 

Diese Sammlung von Funktionen ist etwas zusammengewürfelt und bietet folgendes; 

- Darstellung von Umrandungen in jeder Variante (schrumpfende, sich bewegende...). In 
der PC-Version von GEM sind diese Funktionen dem in der Einleitung erwähnten 
Rechtsstreit zwischen Digital Research und Apple zum Opfer gefallen. 

- Änderung des Mauszeigers 

- Abfrage des aktuellen VDI-Handles und anderer Informationen über die von den AES 
benutzte VDI-Workstation 
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- Abfrage von Position und Zustand der Maus und der “Umschalt-Tasten” Shift, Control 
und Altemate. 


Die Scrap-Bibliothek 

Viele Atari-Anwender haben sich wahrscheinlich schon einmal gefragt, warum bei GEM in 
keiner Weise die beim Apple Macintosh so beliebte “Zwischenablage” verwirklicht ist. Die 
Antwort könnte glücklich und traurig zugleich stimmen: Die dafür notwendigen Funktionen 
sind nämlich allesamt vorhanden — allerdings werden sie nur von einer kleinen Zahl von Pro¬ 
grammen richtig benutzt. 

Einige der positiven Ausnahmen sind “SciGraph” (SciLab GmbH), “Clipboard” (ein Public- 
Domain-Programm von Dieter und Jürgen Geiß), “Gemini” (der alternative Desktop) und - 
mit Einschränkungen - “Wordplus”. 

Die AES-Zwischenablage ist nichts anderes als ein ganz normales Verzeichnis -normalerwei¬ 
se auf einer Festplatte. Die Funktionen “scip_read()” und “scrp_write()” dienen lediglich da¬ 
zu, den Namen dieses Verzeichnisses zu setzen bzw. abzufragen. Leider wird im Atari-AES 
kein Verzeichnis vorinitialisiert. Daher sollte man in eigenen Programmen etwa folgender¬ 
maßen vorgehen: 

1. Verzeichnispfad mit “scrp_read()” abfragen. Wenn das Ergebnis keine leere Zeichenkette 
ist, dann ist man schon fertig - ein anderes Programm hat bereits den Pfad gesetzt. Norma¬ 
lerweise ist der Pfad mit “\”- abgeschlossen, sonst muß man es selbst anhängen. 

2. Entscheiden, wo das Clipboard angelegt werden soll. Vorschlag von Atari: Falls Lauf¬ 
werk C: existiert (“DsetdrvO” benutzen!), das Verzeichnis “C:\CLIPBRD\” benutzen. 
Andernfalls “A:\CLIPBRD\” nehmen oder den Benutzer fragen. Bei notwendigem 
Anlegen des Verzeichnisses sollte man nicht vergessen, mögliche Fehler korrekt auszu¬ 
werten (z. B. bei schreibgeschützten Medien). 

Anderenfalls gilt es, einen anderen Ort zu finden. Normalerweise versucht man es 
zunächst mit dem Verzeichnis “CLIPBRD” im Wurzelverzeichnis des Bootlaufwerks 
(siehe Systemvariable “_bootdev”). Der vollständige Pfad wäre dann also “C:\CLIPBRD\”. 

3. Sicherstellen, daß das ausgewählte Verzeichnis auch tatsächlich funktioniert und 
beschreibbar ist. 

Ebenso wie beim Macintosh-Clipboard kann man auch unter GEM immer nur ein Datenobjekt 
auf einmal ablegen. 



AES-Betriebssystemroutinen 


573 


Dabei sind allerdings mehrere Formate möglich. Um Daten im Clipboard abzulegen, muß man 
also: 

1. alle Clipboard-Dateien, die auf die Maske “SCRAP.*” passen, löschen. 

2. die abzulegenden Daten in einem oder mehreren Formaten sichern. Der Dateiname ist 
dabei immer “SCRAP”, die Namenserweiterung hängt vom gewählten Format ab. Nach 
Möglichkeit sollte immer eines der folgenden Standardformate dabei sein: 

TXT ASCII-Textdatei, jede Zeile mit CR/LF abgeschlossen 

GEM GEM-Metadatei (siehe VDI-Dokumentation) 

IMG GEM-Rasterbild (siehe Anhang) 

Zusätzlich kann man eines oder mehrere zusätzliche Formate unterstützen. Der Empfän¬ 
ger hat dann die Möglichkeit, das Format mit den “meisten” Informationen zu benutzen. 
Weitere gebräuchliche Formate sind: 

ASC ASCII-Textdatei, jeder Absatz mit CR/LF abgeschlossen 

CSV ASCH-Datei mit durch Kommata getrennten Zahlen 

DIF Export-Datei von Tabellenkalkulationen 

IWP Wordplus-Format 

RTF Microsoft Rieh Text Format 

EPS Encapsulated PostScript 

TEX TeX 

CVG Calamus Vektorgrafik-Format 

Das empfangende Programm sollte zunächst überprüfen, welche der vorhandenen Dateien die 
meisten Informationen enthält, und dann diese Datei nehmen. 

Nochmals zur Erinnerung: Jede der Dateien enthält prinzipiell die gleichen Informationen, nur 
eben in einem anderen Format! Wordplus zum Beispiel importiert “SCRAP.TXT” nur dann, 
wenn “SCRAP. 1WP” nicht gefunden werden konnte. 
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Beim Import von Textdaten aus dem Clipboard sollte man übrigens auch mit solchen Dateien 
zurechtkommen, bei denen das “Carriage Return” am Zeilenende fehlt und nur ein “Linefeed” 
als Zeilentrenner benutzt wird - viele UNIX-basierten Programme legen solche Textdateien 
an! 

Wer schon einmal an einem Macintosh gearbeitet hat, wird auch das “Album”-Accessory 
kennen, das anscheinend mehrere Datensätze im Clipboard verwaltet. Auch das könnte man 
unter GEM leicht verwirklichen: Man braucht nur ein Accessory, das eine kleine “Datenbank” 
für Dateien in verschiedenen Formaten bereitstellt und Daten aus dem Clipboard importieren 
und in das Clipboard exportieren kann. 

Für die aktuelle GEM-Realität ist das AES-Clipboard zwar brauchbar, aber teilweise nur 
schwierig zu benutzen. Die wichtigsten Einschränkungen sind: 

- Es gibt keine Standardnachricht, mit der anderen Prozessen mitgeteilt werden könnte, 
daß sich der Inhalt des Clipboards geändert hat. 

Eine direkte Kommunikation wie beim “DDE” (Dynamic Data Exchange) unter 
Microsoft Windows ist nicht möglich. 

Beide Probleme werden mit einiger Sicherheit in einer multitaskingfähigen GEM-Version 
beseitigt werden. 


Die Dateiauswahl-Bibliothek 

Die Dateiauswahlbox braucht kaum noch genau erklärt zu werden - jedem, der schon einmal 
eine GEM-Anwendung benutzt hat, ist sie bekannt. Im GEM 1.0 war sie noch ob ihrer 
Unzuverlässigkeit (Abstürze, Limit für die Anzahl der Dateien) und der unpraktischen 
Bedienung (Laufwerkswahl ausschließlich per Tastatur) sehr unbeliebt. Seit GEM 1.4 ist sie 
nun aber nicht nur relativ stabil, sondern auch komfortabel zu bedienen. 

Dennoch seien noch einmal kurz die Vorteile aufgezählt: 

Der Anwender kann sehen, welche Dateien es gibt, und läuft nicht Gefahr, sich bei der 
Eingabe des Namens zu vertippen. 

- Die Dateiauswahl funktioniert in allen Programmen auf gleiche Art und Weise. 

- Residente Programme können den Betriebssystemaufruf abfangen und eine eigene, 
leistungsfähigere Routine installieren, die dann von allen Programmen benutzt wird. 
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- Minimaler Aufwand beim aufrufenden Programm. 

- Das eigene Programm braucht sich nicht um die Details des verwendeten Dateisystems 
zu kümmern. 

Doch es gibt auch Nachteile, die nicht verschwiegen werden sollen: 

- Vor GEM 1.4 relativ fehleranfällig bei kritischen BIOS-Fehlem. 

- Vor GEM 1.4 keine Möglichkeit, einen erklärenden Text in die Dialogbox aufzunehmen 
(siehe “fsel_exinput()”). 

- Es werden nicht alle für Dateinamen erlaubten Zeichen akzeptiert (siehe GEMDOS- 
Einleitung). Andererseits können einige Zeichen eingegeben werden, die eigentlich 
nicht in Dateinamen auftreten dürfen (wie zum Beispiel nationale Sonderzeichen). 

- Es können nicht alle vorhandenen Laufwerke direkt angewählt werden (unter Meta-DOS 
kann es bis zu 26 Laufwerke geben). 

- Eigene Verbesserungen bei der Dialogbehandlung (Tastaturbedienung, automatisches 
Sichern des Bildschirmhintergrunds) können nicht übertragen werden. 

- ln der Pfadangabe kann nur eine Suchmaske anstelle einer Liste von Suchmasken wie 
unter PC-GEM angegeben werden. 

Wer es aus den oben genannten Gründen für nötig hält, statt dessen eine eigene Routine zu 

benutzen, sollte folgende Ratschläge beherzigen: 

- Als Option die normale Systemfunktion anbieten. 

- Fest eingefahrene Gewohnheiten der Benutzer nicht unnötig stören! 


Die Fenster-Bibliothek 

Einleitung 

Mit Fenstern dürfte jeder Atari-Programmierer vertraut sein - schließlich kennt man sie aus 
Desktop und vielen anderen GEM-Applikationen. Doch bevor wir uns den technischen Details 
zuwenden, soll erst einmal die gar nicht so dumme Frage untersucht werden, wozu es eigent- 
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lieh Fenster gibt - schließlich läßt sich nicht bestreiten, daß sie auch wertvolle Bildschirmfläche 
wegnehmen. 

Ein wichtiger Grund ist die Multitaskingfahigkeit von GEM - auch wenn in den aktuellen 
Versionen nur ein Hauptprogramm und sechs Accessories möglich sind. Wie - wenn nicht mit 
Hilfe von mehreren, überlappenden Fenstern - sollte es möglich sein, die Bildschirmausgaben 
mehrerer AES-Prozesse zu koordinieren? Wer also in eigenen Programmen egoistisch unter 
Umgehung des Fenstersystems direkt auf den Bildschirmhintergrund ausgibt, nimmt den 
Anwendern die Möglichkeit, die Multitaskingmöglichkeiten der AES zu nutzen. 

Auch die große Vielfalt von Bildschirmen (von 320 * 200 Punkten auf dem ST bis zu Auf¬ 
lösungen von über 1000 * 1000 Pixeln in 16 Millionen Farben) lassen die Direktausgabe auf 
dem Hintergrund wie einen schlechten Scherz erscheinen. 

Niemand wird sich einen Großbildschirm kaufen, um in der Textverarbeitung 160 Zeichen in 
eine Textzeile zu zwängen. Nur mit verschiebbaren und in der Größe verstellbaren Fenstern 
kann sich ein Programm sinvoll an jedes Bildschirmformat anpassen. 

Und schließlich ist es für GEM-Änwendungen Standard, daß sie mehrere Dokumente gleich¬ 
zeitig bearbeiten können, schon um das Ausschneiden und Einfügen von Dokumentteilen zu 
ermöglichen. Wie anders als durch die Nutzung der GEM-Fenster sollte man dieses Ziel kom¬ 
fortabel erreichen? 


Konzept 

Um die AES-Fensterfunktionen korrekt und effizient benutzen zu können, muß man ihre 
Funktionsweise genau verstehen. Daher zuerst eine Liste von Funktionen, um die sich die AES 
nicht kümmern: 

- Die Verwaltung von Koordinaten: Programme, die Bildschinmausgaben in Fenstern 
machen wollen, müssen Koordinaten im Fenster selbsttätig in absolute Bildschirmkoor- 
dinaten umrechnen. 

- Das Puffern von Bildausschnitten: die AES-Fensterfunktionen bieten keine Möglichkeit, 
diese Aufgabe den Programmen abzunehmen. Statt dessen werden Nachrichten ver¬ 
schickt, die über die neu zu zeichnenden Bildausschnitte Auskunft geben. 

Man tut also gut daran, sich die AES-Fensterbibliothek zunächst nur als eine Sammlung von 
Routinen vorzustellen, die sich mit der Verwaltung rechteckiger Bildausschnitte, der Fenster, 
befaßt. 
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Rechteckliste 

Fenster können sich bekanntlich gegenseitig überlappen. Die AES nehmen sich dieses Pro¬ 
blems an, in dem sie für jedes Fenster die sichtbaren Ausschnitte in mehrere Rechtecke auftei¬ 
len. Gemeinsam bilden sie die “Rechteckliste” eines Fensters, die ein Programm mit mehreren 
aufeinanderfolgenden Aufrufen der Fensterbibliothek erfragen kann. 

Dabei beachte man, daß Fenster auch teilweise außerhalb des Bildschirms liegen können - 
man muß also erst die Schnittfläche der Rechtecke mit dem sichtbaren Bildschirm bilden. 

Dazu eine Beispielfunktion: 

/* GEM-Standardstruktur für Rechtecke */ 

typedef struct 

{ 

WORD g_x; /* X-Position */ 

WORD g_y; /* Y-Position */ 

WORD g_w; /* Breite */ 

WORD g_h; /* Höhe */ 

} GRECT; 

/* Schnittfläche zweier Rechtecke bilden. Der Returnwert ist genau 
dann Null, wenn sich die Rechtecke nicht überschneiden. Die 
zweite GRECT-Struktur wird mit den Koordinaten der Schnittfläche 
überschrieben */ 

WORD rcJLntersect (GRECT *pl, GRECT *p2) 

{ 

WORD tx, ty, tw, th; 

tw = min (p2->gx + p2->gw, pl->gx + pl->gw); 

th = min (p2->gy + p2->gh, pl->gy + pl->gh); 

tx = max (p2->gx, pl->gx); 

ty = max (p2->gy, pl~>gy); 

p2->gx = tx; 

p2~>gy = ty; 

p2->gw - tw - tx; 

p2->gh = th - ty; 

return ((tw > tx) && (th > ty)); 


1 
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Die Rechtecklisten ändern sich natürlich jedesmal dann, wenn irgendetwas an den Fenstern 
verändert wird (Lage oder Größe, Reihenfolge, Anzahl etc.). Fatal wäre natürlich, wenn dies 
während der Abfrage der Rechteckliste und damit verbundenen Bildschirmausgaben stattfin¬ 
den würde. Die AES bieten daher ein spezielles Protokoll an: Jedes Programm, das Rechteckli¬ 
sten abrufen und dabei Bildschirmausgaben machen möchte, muß dies mit der Funktion 
“ wind_update()” ankündigen. Damit haben die AES die Möglichkeit, bei Bedarf den aufrufen¬ 
den Prozeß so lange zu blockieren, bis er gefahrlos Weiterarbeiten kann. 

Kontrollelemente 

Damit sind natürlich noch nicht alle Aufgaben der Fensterfunktionen genannt - zu einem 
Fenster gehören nicht nur der “Arbeitsbereich” (“work area”), in den Programme ausgeben 
dürfen, sondern auch die “Kontrollelemente”, wie Schließbox oder Slider. Für die Verwaltung 
dieser Fensterelemente ist allein der Screen Manager zuständig. Das Anwendungsprogramm 
gibt beim Anlegen des Fensters lediglich an, welche Elemente benutzt werden sollen. 

Die Interaktion mit den Kontrollelementen wird vollständig vom Screen Manager übernom¬ 
men. Soisteres, der beim Verändern der Fenstergröße die neuen Umrisse des Fensters anzeigt. 
Hat dann am Ende tatsächlich eine Veränderung stattgefunden, wird eine entsprechende 
Mitteilung an den Besitzer des betreffenden Fensters geschickt. Konsequenz ist, daß das 
Anwendungsprogramm die endgültige Entscheidung darüber trifft, ob und wie es die Wün¬ 
sche des Benutzers erfüllt. 

Diese Freiheit darf man freilich nicht mißbrauchen. Wenn man beispielsweise nicht auf eine 
WM_CLOSE-Mitteilung zu reagieren gedenkt, sollte man gar nicht erst ein Schließ-Feld 
erscheinen lassen! Völlig unakzeptabel ist es, Fenster-Kontrollelemente für andere Zwecke 
- etwa die Umschaltung zwischen zwei verschiedenen Betriebsarten - zu mißbrauchen. 

Hier eine Liste der Kontrollelemente und der Reaktionen, die normalerweise damit verbunden 
sein sollten: 

Titelzeile Text, der im oberen Fensterrand als Beschriftung erscheint. Sollte laut Original- 

Dokumentation maximal 80 Zeichen umfassen. Normalerweise werden am 
Anfang und am Ende je ein Leerzeichen angefügt. 

Infozeile Zusätzliche Informationszeile, die normalerweise unterhalb der Titelzeile auf¬ 

taucht und ebenso bis zu 80 Zeichen Text aufnehmen kann. 

Schließfeld Kleine Box zum Schließen des Fensters (normalerweise links oben in der Ecke). 
Ein Mausklick hierhin führt zu einer “WM_CLOSE”-Nachricht. 
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Volle Größe “Fullbox” - kleine Box zur Umschaltung zwischen maximaler und 

aktueller Fenstergröße (normalerweise rechts oben in der Ecke). Ein 
Anklicken der “Fullbox” zieht eine “WM_FULLED”-Nachricht nach 
sich. 

Bewegungsbalken “Move bar” - nimmt den gleichen Platz wie die Titelzeile ein und 
erlaubt es dem Anwender, mit Hilfe einer Umrißlinie das Fenster neu 
zu positionieren. Resultat ist eine “WM_MOVED”-Mitteilung. 

Größenfeld Kleine Box rechts unten im Fenster, die eine Veränderung der 

Fenstergröße ermöglicht. Der Anwender sieht dabei nur einen Umriß 
mit der neuen Fenstergröße. Nach Abschluß der Operation wird eine 
“WM_SIZED”-Mitteilung verschickt. 

Aufwärts-Pfeil Kleine Box mit Aufwärtspfeil am rechten Fensterrand. Nach Anklicken 

erhält das Programm eine “WM_ARROWED"-Mitteilung. 

Abwärts-Pfeil 

Rechts-Pfeil 

Links-Pfeil Analog zum Aufwärts-Pfeil. 

Vertikaler Balken Dieses Kontrollelement liegt zwischen Aufwärts- und Abwärtspfeil 
und besteht aus einem Hintergrundobjekt und dem Slider. Die Größe 
des Sliders zeigt dabei an, wie sich der sichtbare Anteil zur Dokument¬ 
größe verhält. Mausklicks über und unter den Slider führen zu 
“WM_ARROWED”-Mitteilungen, die als Aufforderung, um einen 
Fensterinhalt in die betreffende Richtung zu blättern, interpretiert wer¬ 
den sollten. Ein Verschieben des Sliders zieht eine WM_VSLID”-Mit- 
teilung nach sich. 

Horizontaler Balken Analog zum vertikalen Balken. 

Achtung: Man darf niemals Annahmen über Größe, Lage und Position der Fensterelemente 
machen - es ist durchaus möglich, den AES einen anderen Fenstermanager unterzuschieben, 
bei dem die Fensterkontrollen ganz anders aussehen und auch an anderer Stelle liegen. Die 
Funktion “wind_calc()” erlaubt es, auf portable Art und Weise aus der Gesamtfläche den 
Arbeitsbereich (und umgekehrt) zu berechnen. 

Ab Atari-GEM 3.0 kann man mit “wind_set()” jedem Kontrollelement eigene Farben und 
Füllmuster zuordnen - und zwar getrennt für aktive und inaktive Fenster. Die Einstellung kann 
entweder für ein spezielles oder als Default für alle neu erzeugten Fenster geschehen. Diese 
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Aufgabe wird normalerweise vom XCONTROL-Modul “Fensterfarben” übernommen. Lei¬ 
der ist es nicht möglich, die aktuellen Einstellungen abzufragen. 


Das Desktop-Fenster 

Eine besondere Rolle nimmt Fenster Null, das Desktop- oder Hintergrund-Fenster, ein. Es 
nimmt die gesamte Bildschirmfläche in Anspruch, ist immer geöffnet und kann auch nicht 
geschlossen werden. Der Arbeitsbereich ist die Fläche unter der Menüleiste. Nur in diesem 
Arbeitsbereich dürfen andere Programme Bildschiimausgaben machen oder eigene Fenster 
öffnen. 

Normalerweise erscheint der Arbeitsbereich des Desktop-Fensters als solide grüne Fläche (bei 
Farbbetrieb) bzw. als graues Raster (auf monochromen Bildschirmen). Der Screen Manager 
kümmert sich völlig selbsttätig um den Redraw. Anwendungsprogramme können mittels 
“wind_set()” einen beliebigen anderen Objektbaum als Hintergrund verankern. Auch dann 
kümmert sich der Screen Manager um das fällige Neuzeichnen von Bildausschnitten. Ein 
bekanntes Beispiel ist das Desktop, das die Laufwerkssymbole als eigenständige Objekte im 
selbstinstallierten Objektbaum verwaltet. Obwohl diese Möglichkeit natürlich sehr verlockend 
ist, gibt es etliche Gründe, die gegen eine Benutzung des Desktop-Fensters sprechen: 

- Unter Atari-GEM ist es nicht möglich, auf saubere Art und Weise Farbe und Füllmuster 
des Standardhintergrunds abzufragen. Die Folge ist die sehr häßliche Änderung der 
Hintergrundfarbe beim Starten von Programmen, die einen eigenen Hintergrund instal¬ 
lieren. 

- Auch unter einem multitaskingfähigen GEM kann es nur einen Bildschirmhintergrund 
geben. Der sollte dem Programm Vorbehalten bleiben, das daraus den meisten Nutzen 
ziehen kann - und das ist das Desktop bzw. ein Programm, das als Desktop-Ersatz konzi¬ 
piert ist (auf dem Macintosh sieht es übrigens genauso aus: Nur der “Finder” greift auf 
den Bildschirmhintergrund zu). 

Fazit: Der Desktophintergrund sollte nach Möglichkeit in eigenen Programmen nicht benutzt 
werden. 


Implementation 

Alle von den AES für Fenster benutzten Datenstrukturen sind statisch, haben also eine fixe 
Länge. Das liegt nicht etwa daran, daß die Programmierer von Digital Research zu dumm für 
eine dynamische Verwaltung waren. Der Grund ist vielmehr darin zu suchen, daß ein dyna- 



AES-Betriebssystemroutinen 


581 


misches Nach-Anfordern von Speicher beim Beenden von Programmen zu einer häßlichen 
Zersplitterung des freien Speichers führen würde. 

Die Folge ist, daß die Fensterzahl auf das kleinstmögliche Level festgesetzt worden ist: für 
jeden AES-Prozeß mindestens ein Fenster. 

So kommt es zur Maximalzahl von acht Fenstern in der aktuellen AES-Version. Zu beachten 
ist auch noch, daß jedes zusätzliche Fenster die Maximallänge einer Rechteckliste erhöht - 
und auch die wird in einem festen Speicherbereich abgelegt. 

Auch wenn man nur selten wirklich mehr als die vorhandenen Fenster benötigt, wäre es schön, 
könnte man vor Start der AES auf irgendeine Weise die Maximalzahl einstellen. Vielleicht 
kann sich Atari ja eines Tages mal mit dieser Idee anfreunden. 

Viele GEM-Applikationen, so auch das Desktop vor Atari-GEM 3.0, schränken sich freiwillig 
auf vier Fenster ein, um für Accessories Fenster freizuhalten. Diese Vorsicht ist allerdings aus 
vielerlei Gründen nicht zu empfehlen: 

- Künftige AES-Versionen werden definitiv mehr Fenster gleichzeitig öffnen können. 

- Jedes Programm, das Fenster benutzt, muß mit einem Fehler bei “wind_create()” rech¬ 
nen. Daher ist es nicht besonders sinnvoll, dem Anwender unnötige Einschränkungen 
aufzuerlegen. 


Prinzipielle Vorgehensweise 

Wenn man Fenster in eigenen Programmen benutzen will, sollte man in etwa folgendermaßen 
vorgehen: 

1. Die Größe der verfügbaren Bildschirmfläche feststellen. Das macht man mit “ wind_get()” 
(“wi_gfield”: WF_WORKXYWH) für Fenster Null (das Desktop-Fenster). 

2. Mit “wind_calc()” berechnet man sodann, wie groß der Arbeitsbereich des Fensters bei 
gegebenen Randkomponenten werden kann. 

3. Man vergleicht die erhaltenen Werte mit der gewünschten Größe (und ärgert sich, wenn 
nicht genug Platz ist). 

Die so festgelegte Größe des Arbeitsbereiches wird zusammen mit den Randkomponenten 
in “wind_calc()” eingespeist, welches daraus die Außenmaße des Fensters berechnet. 


4. 
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5. Das Fenster wird unter Angabe dieser Außenmaße und der Fensterkomponenten 
angemeldet (“wind_create()”). Dabei erhält man entweder eine Fehlermeldung oder die 
Kennung des neuen Fensters. 

6. Das Fenster wird mit “wind_open()” auf den Bildschirm gebracht. Dies löst automatisch 
eine Redraw-Mitteilung über die Arbeitsfläche des Fensters aus. 

7. Das Fenster wird vom Programm benutzt... 

8. Mit “wind_cIose()” wird das Fenster vom Bildschirm gelöscht, kann aber immer noch 
mit “wind_open()” erneut geöffnet werden. 

9. “wind_delete()” entfernt das Fenster endgültig aus dem Speicher und gibt insbesondere 
die Fensterkennung für andere Fenster frei. 

Zum Redraw eines Fensterausschnitts verfährt man wie folgt: 

/* Ausschnitt "area" in Fenster "wh" neuzeichnen. Basiert auf 
Beispielfunktion aus "Professional GEM" (Tim Ören) */ 

void redraw (WORD wh, GRECT *area) 

{ 

GRECT box, full; 

graf_mouse (M_OFF, NULL); /* Maus ausschalten */ 

windjupdate (BEG_UPDATE); /* Rechteckliste sperren */ 

/* Arbeitsbereich von Fenster Null abfragen */ 
wind_get (0, WF_WORKXYWH, &full.g_x, &full.g_y, &full.g_h, 
&full.g__w) ; 

/* erstes Element der Rechteckliste erfragen */ 
wind_get (wh, WF_FIRSTXYWH, &box.g_x, &box.g_y, &box.g_w, 
&box.g_h); 

/* solange gültiges Rechteck (Breite und Höhe ungleich Null)*/ 
while (box.g_w && box.g_h) 

{ 

if (rcjlntersect (Sfull, &box)) /* sichtbar */ 

{ 

if (rc_intersect (area, &box)) /* Überlappung? */ 
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{ 

/* Clipping auf Bereich "box" setzen und 
Fensterinhalt neu ausgeben */ 

) 


/* nächstes Element der Rechteckliste erfragen */ 


} 


wind__get (wh, WF_NEXTX¥WH, &box.g_x, &box.g_y, &box.g_w, 
&box.g_h); 


wind_update (ENDJUPDATE); 
grafjmouse (M_ON, NULL); 


Tips 

Und hier noch ein paar weitere Hinweise zu den Fenster-Funktionen: 

- Viele Programme erlauben es, beim Verlassen Position und Größe der geöffneten Fenster 
zu speichern. Diese Daten sollte man immer auflösungsunabhängig (also zum Beispiel 
relativ zu einem “normalisierten” Koordinatensystem von 32768 * 32768 Punkten) 
speichern. Anderenfalls kann es zu so unschönen Effekten wie bei “Wordplus” kommen 
(Fenster erscheinen innerhalb der Menüleiste oder außerhalb des sichtbaren Bildschirmbe¬ 
reichs). 

- In einigen Programmen werden Fenster an der horizontalen Position “-1” geöffnet, um 
den Arbeitsbereich des Fensters an Position 0 beginnen zu lassen. Dabei verläßt man sich 
nicht nur auf die nicht-dokumentierte Tatsache, daß die AES negative Koordinaten 
korrekt verarbeiten, sondern macht auch eine unsichere Annahme über die Breite der 
Fensterränder. 

Hinzu kommt, daß nicht bei allen Bildschirmen der Bildrand schwarz ist, so daß man nur 
schwer Fenster und Bildrand auseinanderhalten kann. 

~ Der Screen Manager verschickt in mehreren Fällen unnötige Redraw-Mitteilungen, auf 
deren Eintreffen man sich jedoch nicht verlassen sollte. Wenn ein Fenster zum obersten 
Fenster wird, erhält es eine Redraw-Mitteilung über die gesamte Arbeitsfläche - auch 
über die Bereiche, die bereits sichtbar waren. Gleiches gilt für das Vergrößern eines Fen¬ 
sters. 
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Die Resource-Bibliothek 


Einleitung 

Die Resourcen eines Programms sind alle Daten, die normalerweise in der Resource-Datei 
(“*.RSC”) gespeichert sind. Dazu gehören Informationen über Dialoge, Menüs, Icons usw. 
Die Speicherung in einer separaten Datei hat den Vorteil, daß man das Erscheinungsbild 
(insbesondere bei Texten die Sprache) ändern kann, ohne am Programm etwas modifizieren 
zu müssen. 


Die Resource-Datei 

Am Anfang einer solchen Datei steht stets folgende Struktur: 


typedef struct 
{ 


UWORD 

rsh_vrsn; 

/* 

DWORD 

rsh object; 

/* 

UWORD 

rsh_tedinfo; 

/* 

UWORD 

rsh_iconblk; 

/* 

UWORD 

rsh_bitblk; 

/* 

UWORD 

rsh__frstr; 

/* 

UWORD 

rsh_string; 

/* 

UWORD 

rsh imdata; 

/* 

UWORD 

rsh__frimg; 

/* 

UWORD 

rsh trindex; 

/* 

UWORD 

rshjnobs; 

/* 

UWORD 

rshjntree; 

/* 

UWORD 

rsh nted; 

/* 

UWORD 

rsh nib; 

/* 

UWORD 

rsh_nbb; 

/* 

UWORD 

rsh_nstring; 

/* 

UWORD 

rshjaimages; 

/* 

UWORD 

rsh__rssize; 

/* 


} RSHDR; 


null */ 

Position des Objekt-Feldes */ 
Position der TEDINFO-Strukturen */ 
Position der ICONBLK-Strukturen */ 
Position der BITBLK-Strukturen */ 
Position der freien Strings */ 
unbenutzt */ 

Position der Image-Daten */ 

Position der freien Images */ 
Position der Objektbaumtabelle */ 
Gesamtzahl der Objekte */ 

Gesamtzahl der Objektbäume */ 
Gesamtzahl der TEDINFO-Strukturen */ 
Gesamtzahl der ICONBLK-Strukturen */ 
Gesamtzahl der BITBLK-Strukturen */ 
Gesamtzahl der Strings */ 

Gesamtzahl der Images */ 

Gesamtlänge der RSC-Datei */ 


Alle Positionsangaben sind relativ zum Dateianfang zu verstehen. Noch ein Wort zu den 
“freien Strings”. Zu diesen gehören nicht nur die Zeichenketten, in denen sich die Daten für 
Alarmboxen befinden, sondern auch alle anderen Strings, die ein Programm zu seiner Arbeit 



AES-Betriebssystemroutinen 


585 


benutzt. Ein Beispiel dafür wäre der Dateiname einer einzulesenden Datei oder ein Eintrag, 
der mit “menu_text()” in einem Menü vorgenommen wird. 

Diesem Dateikopf folgen die eigentlichen Resource-Daten. Man beachte dabei, daß eine 
Resource-Datei aufgrund der Verwendung von 16-Bit-Werten als Zeiger nur eine Gesamtgröße 
von maximal 64 KByte erreichen kann. Dateien dieses Formats werden von allen RCS- 
Programmen (“Resource Construction Set”) abgespeichert. 


Resourcen im Programm 

Aus mancherlei Gründen kann es sinnvoll sein, Resource-Daten direkt in das Programm 

aufzunehmen. Einige Vorteile sind: 

- In Accessories ist das Nachladen von RSC-Dateien problematisch (Finden der Datei, 
Anfordem von Speicher). 

- In XCONTROL-Moduln darf “rsrc_load()” gar nicht aufgerufen werden (mehr dazu im 
Kapitel über “XCONTROL”). 

- Resource-Dateien dürfen nicht länger als 64 KByte werden. 

Wenn man daher die Resource-Daten direkt einbinden möchte, muß man folgende Probleme 

lösen: 

1. Die Resource-Strukturen vom Resource-Construction-Programm in ein Format bringen 
lassen, das von der benutzten Programmiersprache verstanden wird. Das ist meist nur für 
C-Compiler möglich. 

2. In den RSC-Daten stehen anstelle “echter” Zeiger noch die Indizes der jeweiligen 
Feldelemente. Diese Verweise müssen vom Programm in richtige Zeiger umgerechnet 
werden. Das RCS “Interface” erlaubt es, schon passend initialisierte C-Datenstrukturen 
zu erzeugen. 

3. Schließlich müssen diezeichenorientierten Koordinatenangaben in echte Pixelkoordinaten 
konvertiert werden. Dazu kann die Funktion “rsrc_obfix” benutzt werden. 


Die Shell-Bibliothek 

Die Shell-Bibliothek ist sozusagen die Schaltzentrale im Innern der AES. Sie sorgt für das 
Starten der einzelnen GEM-Prozesse und versorgt sie mit Informationen über ihre 
Arbeitsumgebung. Daneben stellt sie dem Desktop mehrere Hilfsfunktionen zur Verfügung. 
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Beginnen wir mit “shel_read()”: Mitdieser Funktion kann ein Programm auf betriebssystemun¬ 
abhängige Art und Weise Informationen über den eigenen Dateinamen und die übergebenen 
Parameter erfragen. Leider liefert sie nur dann korrekte Resultate, wenn das betreffende Pro¬ 
gramm tatsächlich mit Hilfe der Shell-Bibliothek gestartet worden ist. 

Daher ist es meistens sinnvoller, diese Informationen aus der Basepage und dem Environment 
(ARGV-Verfahren) zu extrahieren. 

“shel_write()” erlaubt es, einen neuen AES-Prozeß zu starten. Dies allerdings erst nach 
Beendigung des eigenen Prozesses und auch nur dann, wenn der Aufrufer zum Programmstart 
tatsächlich die AES-Shellfunktionen benutzt hat. PC-GEM kennt bei dieser Funktion spezielle 
Parameter zum Starten von Programmen im Textmodus (ohne VDI und AES). Künftige AES- 
Versionen werden vermutlich zusätzliche AES-Prozesse starten können, ohne dazu erst den 
aktuellen Prozeß beenden zu müssen. 

Ebenso wie “shel_read()” die betriebssystemabhängige Abfrage der Kommandozeile erspa¬ 
ren soll, ist “shel_envm()” zur portablen Abfrage von Environment-Variablen gedacht. Man 
beachte, daß “sheLenvm()” stets auf das Environment zugreift, das beim Starten der AES 
aktuell war. Hinzu kommen einige Probleme mit der “PATH”~Variablen (siehe unter 
“shel_envm()”), so daß eine sinnvolle Nutzung dieser Funktion kaum möglich ist. Statt dessen 
sollte man das normale GEMDOS-Environment abfragen! 

Nützlicher ist da schon “shel_find()”, das zum Suchen von Dateien benutzt wird. Auch 
“rsrc_load()” nimmt es in Anspruch, um die angegebene RSC-Datei zu finden. Speziell seit 
GEM-Version 1.4 ist “shel_find()” von großer Bedeutung, da das Desktop beim Starten einer 
Applikation unter bestimmten Umständen nicht in das Verzeichnis der Applikation wechselt 
und man daher nur mit “shel__find()” Dateien, die im gleichen Verzeichnis wie das gestartete 
Programm liegen, finden kann. 

Die AES kennen ein Programm, das eine herausgehobene Bedeutung besitzt: das Default- 
Desktop-Programm, das automatisch nach dem Start von GEM und nach dem Beenden einer 
GBM-Applikation geladen wird. Im Atari-GEM ist das Desktop fest im ROM verankert und 
zusammen mit den AES zu einem Programm zusammengefaßt. Unter PC-GEM kann der 
Name auch nachträglich noch mit “shel_rdef()” abgefragt und mit “shel_wdef()” verändert 
werden. 

Speziell für dieses Programm gibt es den sogenannten “Shell-Puffer” - einen statischen 
Speicherbereich, der immer resident bleibt. Er erlaubt es dem Desktop, seine aktuellen 
Einstellungen vor jedem Programmstart zu sichern, ohne erst eine Datei anlegen zu müssen 
(man bedenke, daß 1984 Festplatten noch nicht zur Standardausstattung gehörten). Dieser 
Puffer kann mittels “shel_putQ” beschrieben und mit “shel_read()” ausgelesen werden. 
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Über den Inhalt des Shell-Puffers entscheidet allein das Desktop-Programm. Das Atari- 
Desktop verwaltet den Puffer als Textdatei, die beim Systemstartaus der Datei “DESKTOP.INF” 
(bis einschließlich GEM 1.4) bzw. “NEWDESK.INF” ausgelesen wird. Je nach Desktop- 
Version wird das Ende der Daten durch ein Nullbyte oder Control-Z (ASCII 26) gekennzeich¬ 
net. 


Die XGRF-Bibliothek 

Diese Funktionssammlung ist eine PC-GEM-spezifische Erweiterung. Die beiden XGRF- 
Punktionen erlauben es, Ersatz für die im PC-GEM gestrichenen Routinen für schrumpfende, 
wachsende und sich bewegende Rechtecke zu schaffen. 

AES-Bindings 

Der AES-Parameter-Block 

Ebenso wie beim VDI benutzt man auch bei den AES zur Parameteriibergabe spezielle Ein- 
und Ausgabefelder. Im einzelnen sind das: 

WORD contrl[5]; 

Fünf Werte, mit denen Informationen über die aufgerufene Funktion und ihre Parameter fest¬ 
gelegt werden. Die Belegung ist wie folgt: 

contrl[0] Nummer der AES-Funktion 

contrl[l] Anzahl der 16-Bit-Werte im int_in-Feld 

contrl[2) Anzahl der 16-Bit-Werte im int_out-Feld 

contrl[3] Anzahl der 32-Bit-Werte im addrjn-Feld 

contrl[4] Anzahl der 32-Bit-Werte im addr_ out-Feld 

Darüber, welche Werte vor einem AES-Aufruf gesetzt werden müssen, gibt es keine klaren 
Informationen. Nötig ist es auf jeden Fall für contrl [0], contrl[ 1 ] und contrl[3]. Wenig sinnvoll 
erscheint es für contrl[2] und contrl[4] - schließlich wissen ja die AES-Funktionen selbst, wie 
viele Werte sie in den Ausgabefeldem zurückliefem. 



588 


ATARI Profibuch 


Die mit dem Original-Entwicklungspaket mitgelieferten Bindings (unten beschrieben) setzen 
allerdings alle Werte des Arrays. 

WORD global[12]; 

Dieses Feld enthält globale Daten für die Applikation und wird teils von “appl_init()”, teils 
von anderen AES-Funktionen benutzt. Genauere Informationen dazu im Abschnitt über die 
Applikations-Bibliothek. 

WORD int_in[16]; 

In diesem Array werden alle 16-Bit großen Parameter übergeben. 

WORD int_out[7]; 

Hier übergeben AES-Funktionen alle 16-Bit großen Rückgabewerte. 

LONG addr_in[2]; 

Dient zur Übermittlung von Zeigerparametem (wie Zeiger auf Zeichenketten) an AES- 
Funktionen. 


LONG addr_out[l]; 

Hier werden 32-Bit große Rückgabewerte zurückgeliefert. Wird zurZeit nurfür “rsrc_gaddr()” 
benutzt. 


Die Anfangsadressen der sechs Parameterfelder werden im “AES Parameterblock” abgelegt: 


typedef struct 

{ 

WORD *cb_pcontrol; 
WORD *cb_j?global ; 
WORD *cb_pintin; 
WORD *cb_pintout; 
LONG *cb_padrin; 
LONG *c±>_padrout; 

} AESPB; 


/* Zeiger auf contrl[] */ 

/* Zeiger auf global[] */ 

/* Zeiger auf int_in[] */ 

/* Zeiger auf int_out[] */ 
/* Zeiger auf addr_in[] */ 
/* Zeiger auf addr_out[] */ 


Beim Aufruf von AES-Funktionen ist damit nur noch ein Zeiger auf den Parameterblock zu 
übergeben. 
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Der AES-Trap 

Zum Aufruf einer AES-Funktion lädt man Datenregister DO mit der Konstante 200 und Dl 
mit der Anfangsadresse des AES-Parameterblocks und macht einen “TRAP #2”-Aufruf: 

.text 

.globl __crystal 
_crystal: 

move.l 4(sp),dl 
move.w #200,dO 

trap #2 

rts 

Die Bezeichnung “crystar stammt aus der Ursprungszeit von GEM, als Digital Research noch 
nicht den endgültigen Namen gefunden hatte. Darüber, welche Register verändert werden, 
gibt es keine klaren Informationen. Tatsache aber ist, daß die entsprechenden Routinen im 
ROM alle Register retten. Rückgabewerte erhält man nicht in Registern, sondern im “int_out”- 
und “addr_out”-Feld. 

Eine weitere wichtige Frage ist, inwieweit GEM fehlertolerant ist, das heißt, ob es eine 
Absicherung gegen Abstürze infolge fehlerhafter Aufrufe gibt: Darauf kann man nur mit 
einem klaren Jein antworten. Falsche AES-Funktionsnummem werden von den AES vorbild¬ 
lich mit einer Alarm-Box (falsche Funktionsnummer) quittiert. Falsche Parameter hingegen 
werden nur in den seltensten Fällen vernünftig abgefangen und führen normalerweise zu 
Abstürzen oder anderem Fehlverhalten. 

AES-Aufrafe aus dem Supervisor-Modus sind nur schwer durchzuführen. Dies ist auch nicht 
weiter schlimm, da sich Aufrufe aus Interrupts heraus sowieso verbieten - die AES sind nicht 
re-entrant. Wer es dennoch probieren will, muß folgende Punkte beachten: 

- Viele AES-Funktionenkehren auch dann im User-Modus zurück, wenn man sie aus dem 
Supervisor-Modus heraus aufgerufen hat. Daher muß man nach jedem Aufruf mittels 
“Super(lL)” feststellen, ob der Modus wieder korrigiert werden muß. 

- Bei AES-Aufrufen dürfen sich User-Stack und Supervisor-Stack nicht überschneiden. 
Genau dies ist jedoch der Fall, wenn man mittels “Super(OL)” in den Supervisor-Modus 
geschaltet hatte. Abhilfe: eigenen Supervisor-Stack zu Fuß anlegen. 

- Hinzu kommt, daß die AES sogar überdas Ende des Supervisor-Stacks hinausschreiben. 
Ein “sicherer” Aufruf sollte daher etwa so aussehen (Quelle: “TOS 1.4 Release Notes”): 


; Adresse AESPB (AES Parameter Block) 
; Opcode für AES 
; Trap für GEM 
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char my_stack[8192]; 

old_ssp = Super (&my_stack[8180]);/* nicht ganz aufs Ende! V 
/* Aufrufe im Supervisor-Modus... */ 

Super (old_ssp); 


Ein Beispiel-Binding 

Die Funktion “crys__if’ (“Crystal Interface”) sorgt für die Besetzung des “contrl”-Arrays und 
macht den eigentlichen AES-Aufruf. Dazu bedient es sich einer Tabelle, in der für jede 
einzelne AES-Funktion die Werte für contrl[l], contrl[2] und contrl[3] vermerkt sind: 

.text 

.globl _ctrl__cnts 

.data 
Ctrl cnts: 


.dc.b 

0, 

1, 

0 

* 

appl__init 

.dc.b 

2, 

1 , 

1 

ir 

appl_read 

.dc.b 

2, 

1 , 

1 


appl_write 

• dc.b 

0, 

1 , 

1 

* 

appl find 

.dc.b 

2, 

1 / 

1 

* 

appl_tplay 

.dc.b 

1 , 

1, 

1 

* 

appl_trecord 

.dc.b 

2, 

1, 

0 

* 

appl_bvset 

.dc.b 

o, 

1 , 

0 

* 

appl_yield 

.dc.b 

o. 

0, 

0 

* 

AES 18 

.dc.b 

0, 

1 , 

0 

* 

appl_exit 

.dc.b 

0, 

1 , 

0 

* 

evnt keybd 

.dc.b 

3, 

5, 

0 

* 

evnt_button 

.dc.b 

5, 

5, 

0 

* 

evnt mouse 

.dc.b 

0, 

1, 

1 

* 

evnt_jnesag 

.dc.b 

2, 

1 , 

0 

* 

evnt__timer 

.dc.b 

16 , 

7, 

1 

■k 

evnt multi 

.dc.b 

2, 

1 , 

0 

■k 

evnt_dclicks 

-dc.b 

0, 

0, 

0 

★ 

AES 27 

.dc.b 

o, 

0, 

0 

* 

AES 28 

.dc.b 

0, 

o, 

0 

* 

AES 29 

.dc.b 

1 , 

1 , 

1 

* 

menu bar 
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.dc.b 2, 1, 1 * menu_icheck 

.dc.b 2, 1, 1 * menu_ienable 

.dc.b 2, 1, 1 * menu_tnormal 

.dc.b 1, 1, 2 * menu__text 

.dc.b 1, 1, 1 * menu_register 

.dc.b 1, 1, 0 * menu_unregister 

• dc.b 2, 1, 0 * menu_cl.ick 

.dc.b 0, 0, 0 * AES 38 

.dc.b 0, 0, 0 * AES 39 

.dc.b 2, 1, 1 * objc__add 

.dc.b 1, 1, 1 * obje_delete 

.dc.b 6, 1, 1 * objc_draw 

.dc.b 4, 1, 1 * objc_find 

.dc.b 1, 3, 1 * objc_offset 

.dc.b 2, 1, 1 * objc_order 

.dc.b 4, 2, 1 * objc_edit 

.dc.b 8, 1, 1 * objc__change 

.dc.b 0, 0, 0 * AES 48 

.dc.b 0, 0, 0 * AES 49 

.dc.b 1, 1, 1 * formjäo 

.dc.b 9, 1, 0 * form_dial 

.dc.b 1, 1, 1 * form_alert 

.dc.b 1, 1, 0 * form_error 

.dc.b 0, 5, 1 * form_center 

.dc.b 3, 3, 1 * form_keybd 

.dc.b 2, 2, 1 * form_button 

.dc.b 0, 0, 0 * AES 57 

.dc.b 0, 0, 0 * AES 58 

.dc.b 0, 0, 0 * AES 59 

.dc.b 0, 0, 0 * AES 60 

.dc.b 0, 0, 0 * AES 61 

.dc.b 0, 0, 0 * AES 62 

.dc.b 0, 0, 0 * AES 63 

.dc.b 0, 0, 0 * AES 64 

.dc.b 0, 0, 0 * AES 65 

.dc.b 0, 0, 0 * AES 66 

.dc.b 0, 0, 0 * AES 67 

.dc.b 0, 0, 0 * AES 68 

.dc.b 0, 0, 0 * AES 69 

.dc.b 4, 3, 0 * graf_rubberbox 

.dc.b 8, 3, 0 * graf_dragbox 
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.dc.b 

6, 

1, 

0 

k 

graf movebox 

.dc.b 

8, 

1, 

0 

k 

graf growbox 

-dc.b 

8, 

1, 

0 

* 

graf shrinkbox 

.dc.b 

4, 

1, 

1 

* 

graf watchbox 

.dc.b 

3, 

1, 

1 

* 

graf_s1idebox 

.dc.b 

0, 

5, 

0 

* 

graf_handle 

.dc.b 

1, 

1, 

1 

* 

graf_mouse 

.dc.b 

0, 

5, 

0 

* 

graf_mkstate 

.dc.b 

0, 

1, 

1 

k 

serp read 

.dc.b 

0, 

1, 

1 

k 

serp write 

.dc.b 

0, 

1, 

0 

* 

scrp_clear 

.dc.b 

0, 

0, 

0 

* 

AES 83 

.dc.b 

0, 

ö, 

0 

* 

AES 84 

.dc.b 

o, 

0, 

0 

* 

AES 85 

.de .b 

0, 

0, 

0 

k 

AES 86 

.dc.b 

0, 

0, 

0 

k 

AES 87 

.dc.b 

0, 

0, 

0 

k 

AES 88 

.dc.b 

0, 

0, 

0 

k 

AES 89 

.dc.b 

0, 

2, 

2 

k 

fsel_input 

.dc.b 

0, 

2, 

3 

k 

fsel_exinput 

.dc.b 

0, 

0, 

0 

k 

AES 92 

.dc.b 

0, 

0, 

0 

k 

AES 93 

.dc.b 

0, 

0, 

0 

k 

AES 94 

.dc.b 

0, 

0, 

0 

k 

AES 95 

.dc.b 

0, 

0, 

0 

k 

AES 96 

.dc.b 

0, 

0, 

0 

k 

AES 97 

.dc.b 

0, 

0, 

0 

k 

AES 98 

.dc.b 

0, 

0, 

0 

k 

AES 99 

.dc.b 

5, 

1, 

0 

k 

wind_create 

.dc.b 

5, 

1 r 

0 

k 

wind__open 

.dc.b 

1, 

1, 

0 

k 

wind close 

.dc.b 

1, 

1, 

0 

k 

wind delete 

.dc.b 

2, 

5, 

0 

k 

wind get 

.dc.b 

6, 

1, 

0 

k 

wind set 

.dc.b 

2, 

1, 

0 

k 

wind find 

.dc.b 

1, 

1, 

0 

k 

wind update 

.dc.b 

6, 

5, 

0 

k 

wind_calc 

.dc.b 

0, 

0, 

0 

k 

wind new 

.dc.b 

0, 

1, 

1 

k 

rsre load 

.dc.b 

0, 

1, 

0 

k 

rsrc__free 

. de .b 

2, 

1, 

0 

k 

rsrc_gaddr 
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■ dc.b 

2, 

1, 

1 

* 

rsrc_saddr 

.dc.b 

1 , 

1 , 

1 

* 

rsrc obfix 

.dc.b 

o, 

0 , 

0 

* 

AES 115 

.dc.b 

o, 

0 , 

0 

* 

ÄES 116 

.dc.b 

0 , 

0 , 

0 

* 

AES 117 

.dc.b 

0 , 

0 , 

0 

k 

AES 118 

.dc.b 

0 , 

0 , 

0 

k 

AES 119 

.dc.b 

0 , 

1, 

2 

•k 

shel_read 

.dc.b 

3, 

1, 

2 

k 

sheljwrite 

.dc.b 

1, 

1, 

1 

k 

shel get 

.dc.b 

1 , 

1, 

1 

k 

shel_put 

.dc.b 

0 , 

1, 

1 

k 

shel__find 

.dc.b 

0 , 

1, 

2 

k 

shel_envrn 

.dc.b 

0, 

1, 

2 

k 

shel rdef 

■ dc.b 

0 , 

0 , 

2 

k 

shel wdef 

.dc.b 

0 , 

0 , 

0 

k 

AES 128 

.dc.b 

0 , 

0 , 

0 

k 

AES 129 

.dc.b 

6, 

6, 

0 

k 

xgrf stepcalc 

.dc.b 

.end 

9, 

1 , 

0 

k 

xgrf_2box 


Der AES-Parameter-Block wird direkt vor dem Aufruf der Funktion “appl_init()” initialisiert 
(siehe dort): 

AESPB c; 

WORD crys_if (WORD opcode) 

{ 

WORD i; 

WORD *paesb; 

contrl [0] = opcode; 

paespb = &ctrl__cnts [ (opcode-10) *3]; 

for (i = 1; i < 4; i++) 

control[i] = *paespb++; 

crystal (c); 
return int out[0]; 
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AES-Referenz 

APPL-Funktionen 


APPLINIT (AES 10) 


Diese Funktion initialisiert die GEM-Arrays (namentlich das Global-Feld) und meldet das 
laufende Programm als GEM-Applikation an. Die DR-Dokumentation zu GEM 2.0 gibt an, 
daß die erste Prozeßumschaltung frühestens nach zehn AES-Aufrufen stattfindet. Innerhalb 
dieses Zeitraums sollte man notwendige Speicherallozierungen - sei es mittels “rsrc_load()” 
oder “MallocO” - vornehmen, um eine überflüssige Speicher-Zersplitterung zu vermeiden. 

Bei Accessories ist besondere Vorsicht geboten, da ab GEM 1.4 das Desktop das Laden einer 
Autostart-Anwendung vorsieht. Man darf also nicht davon ausgehen, daß der Rest des Systems 
während der Accessory-Initialisierung stillhält. Dadurch wird alles, was Speicheranfordemngen 
an GEMDOS provoziert (“rsrcJoadQ”, “v_opnvwk(>” etc.), zum Problem: Es könnte bereits 
ein anderer GEMDOS-Prozeß am Ruder sein, bevor man seine eigene Initialisierung beendet 
hat. Bei Beendigung dieses Prozesses wird dann der ganze in der Zwischenzeit allozierte 
Speicher freigegeben! 

Daher sollte die Accessory-Initialisierung 

- gleich nach dem “appl_init()” beginnen (und nicht erst nach der “AC__OPEN”-Mittei- 
lung anfangen) 

- mit “wind_update()” (BEG_UPDATE/END_UPDATE) geklammert werden (damit 
kann man normalerweise das Starten der Autostart-Applikation bremsen). 

Deklaration in C: 

extern AESPB c; 

WORD int_in[16] r int_out[7], contrl[5], global[15]; 

LONG addr_ln[2], addr_out[1]; 

WORD appl_init (void) 

{ 

c. cbjscontrol = control; 
c.cb_pglobal = global; 
c.cbjointin = int^in; 
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c.cb_pintout = int_out; 
c.cb_padrin = addr_in; 
c.cb_padrout = addr_out; 
control[4] = 0; 
crys__if (10) ; 
return int_out[0]; 

} 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

10 

Opcode für APPLJNIT 

contrl+2 

contrlfl] 

0 

# Einträge in int_in 

contrl+4 

contrl [2] 

1 

# Einträge in int_out 

contrl+6 

contrl [3] 

0 

# Einträge in addrjn 

contrl+8 

contrl[4] 

0 

# Einträge in addr_out 

int_out 

int_out[0] 

Return-Wert 


Parameter: 

appl_init(): Bei erfolgreicher Initialisierung die Identifikationsnummer für die Applikation. 

Im Fehlerfall erhält man —1. Dann sollte man das Programm mit einer 
Fehlermeldung abbrechen und insbesondere weitere AES-Aufrufe vermeiden 
(viele Bibliotheken liefern übrigens immer die 1!). Die AES selbst merken sich 
die Kennung im internen GLOBAL-Feld der Applikation. 

Bemerkungen 

Wenn man “appl_init(>” auffuft, ohne daß die AES betriebsbereit sind (also aus dem AUTO- 
Ordner heraus), wird speziell die AES-Versionsnummer im GLOBAL-Feld nicht gesetzt. 
Wenn man dort vorher eine Null hineinschreibt, kann man also leicht feststellen, ob das 
Programm aus dem AUTO-Ordner heraus gestartet worden ist. Dieses Verfahren ist zwar 
nirgendwo offiziell dokumentiert, wird aber ebenfalls vom Atari-Mausbeschleuniger 
“MACCEL3” verwendet. 
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APPLREAD (AES 11) 

Liest eine bestimmte Anzahl von Bytes aus einem Ereignispuffer (Message Pipe). 

Deklaration in C: 

WORD appl__read (WORD rwid, WORD length, void *pbuff) 

{ 

int_in[0] = rwid; 
int_in[l] = length; 
addr_in[0] = buff; 
return crys_if (11); 

) 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

11 Opcode für APPL_READ 

contrl+2 

contrl[l] 

2 # Einträge in int_in 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrl [3] 

1 # Einträge in addrjn 

contrl+8 

contrl [4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

rwid 

int_jn+2 

int_in[l] 

length 

addr_in 

addr_in[0] 

pbuff 

int_out 

int_put[0] 

Return-Wert (0: Fehler) 


Parameter: 

rwid: id der Applikation, aus deren Ereignispuffer (Message Pipe) gelesen werden 

soll (normalerweise der eigene!) 
length: Anzahl der zu empfangenden Bytes 

pbuff: Anfangsadresse des Puffers, in dem die Nachricht abgelegt werden soll 
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APPLWRITE (AES12) 


Schreibt eine Anzahl von Bytes in einen Ereignispuffer (Message Pipe). Eine besonders nette 
Anwendung dieser Funktion ist es, wenn eine Applikation sich selbst eine WM_JREDRAW- 
Mitteilung schickt. Mehrere solcher Ereignisse werden nämlich von den AES nach Möglich¬ 
keit zu einer einzigen Mitteilung zusammengefaßt. 

Leider gibt es einen kleinen Haken: der AES-Dispatcher legt bei “appl_write()” einen Prozeß 
schlafen, wenn die Message-Queue bereits voll ist. Wenn aber alle bereits in der Message- 
Queue liegenden Mitteilungen an das eigene Programm gerichtet sind, kommt es zum System¬ 
stillstand - nichts geht mehr! 

Abhilfe: Durch einen Mechanismus im eigenen Programm dafür sorgen, daß nicht mehrere 
Mitteilungen auf einmal in die Message-Queue eingespeist werden. 

Deklaration in C: 

WORD appl_write (WORD rwid, WORD length, void *pbuff) 

{ 

int_in[0] = rwid; 
int_in[l] = length; 
addr_in[0] = pbuff; 
return crys_if (12); 

1 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

12 Opcode für APPL_WRITE 

contrl+2 

contrlfl] 

2 # Einträge in int_in 

contrl+4 

contrl [2] 

1 # Einträge in int_out 

contrl+6 

contrI[3] 

1 # Einträge in addrjn 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

int_in 

intjn[0] 

rwid 

int_in+2 

int_in[l] 

length 

addrjn 

addr_in[0] 

pbuff 

int_out 

int_out[0] 

Retum-Wert (0: Fehler) 
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Parameter: 

rwid: id der Applikation, zu der die Mitteilung gesendet werden soll (im Normalfall 

ein anderes Programm, z. B. ein Accessory) 

length: Anzahl der zu sendenden Bytes (mindestens der Inhalt eines Message-Puffers, 

also 16 Bytes). Eigene Versuche ergaben, daß in den vorhandenen AES-Ver- 
sionen maximal 128 Bytes erlaubt sind. 

pbuff: Anfangsadresse des Puffers, in dem sich die zu sendende Information befindet 

(sollte in den ersten 16 Bytes dem AES-Standardformat für Mitteilungen ent¬ 
sprechen) 


AES-Betriebssystemroutinen 


599 


APPLFIND (AES 13) 


Um Informationen mit parallel laufenden Programmen austauschen zu können, muß man 
zunächst deren Identifikationsnummern (id) feststellen (siehe zum Beispiel bei “appl_read() n 
und “appLwrite()”).Mit“appl_find()’’kannmandieIdentifikationsnummereiner Applikation, 
deren Dateiname bekannt ist, ermitteln - allerdings nur, wenn sie mittels “shel_write()” 
gestartet worden ist. 

Leider arbeitet diese Funktion nicht ganz fehlerfrei. Hat man eine Applikation beendet und 
ist zum Desktop zurückgekehrt, behauptet “appLfindO” immer noch, die Applikation sei im 
Speicher! Die Ursache hierfür ist darin zu suchen, daß das Desktop auf dem Atari keine echte 
Applikation ist und daher die AES von seiner Existenz nichts wissen. Daher wird auch der 
Name der vorher aktiven Applikation nicht gelöscht. 

Auf dem Atari hat das aktive Hauptprogramm immer die Identifikationsnummer 0. Nummer 
1 ist der Screen Manager (SCRENMGR ist der Name der Applikation). Die folgenden 
Nummern werden an die Accessories vergeben. Dies kann natürlich unter einer multitasking¬ 
fähigen GEM-Version anders sein. 


Deklaration in C: 

WORD appl_find (const CHAR *pname) 
{ 

addr_in(0] = pnarae; 
return crys_if (13); 

1 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

13 

Opcode für APPL_FIND 

contrl+2 

contrl[l] 

0 

# Einträge in int_in 

contrl+4 

contrl [2] 

1 

# Einträge in int_out 

contrl+6 

contrl[3] 

1 

# Einträge in addrjn 

contrl+8 

contrl[4] 

0 

# Einträge in addr_out 

addr_in 

addr_in[0] 

pname 

int_out 

int_out[0] 

Return-Wert (-1: Fehler) 
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Parameter: 

pname: 

appl_find(): 


Name der zu suchenden Applikation. Dabei handelt es sich nur um den eigent¬ 
lichen Dateinamen des Programms (also ohne Extension). Ist dieser kürzer, 
muß der String mit Leerzeichen aufgefüllt werden. 

Identifikationsnummer des gesuchten Programms (oder -1, wenn es nicht 
gefunden werden konnte) 



AES-Betriebssystemroutinen 


601 


APPLTPLAY (AES 14) 


Die AES erlauben es, Benutzeraktionen (also Mausbewegungen, Tastendrücke etc.) wie ein 
Bandgerät zu speichern und anschließend wieder abzuspielen. Diese Wiedergabefunktion 
übernimmt “appl_tplay()”. 

Deklaration in C: 

WORD appl__tplay (APPLRECORD *tbuffer, WORD tlength, WORD tscale) 

{ 

int_in[0] = tlength; 
int_in[l] = tscale; 
addr_in[0] = tbuffer; 
return crys_if (14); 

} 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

14 Opcode für APPL_TPLAY 

contrl+2 

contrl [1) 

2 # Einträge in int_in 

contrl+4 

contrl[2j 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

1 # Einträge in addr_in 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

tlength 

int_in+2 

int_in[l] 

tscale 

addr_in 

addr_in[0] 

tbuffer 

int_out 

int_out[0] 

Retum-Wert (immer 1) 


Parameter: 

tlength: Anzahl der wiederzugebenden Ereignisse 

tscale: GeschwindigkeitsfaktorbeimAbspielenderEreignisse(50:halbeGeschwindig- 

keit, 100: normale Geschwindigkeit, 200: doppelte Geschwindigkeit usw.) 
tbuffer: Zeiger auf den Speicherbereich, in dem die Ereignisse gespeichert worden sind 
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APPL TRECORD (AES15) 


Dient, analog zu “appl_tplay()”, zum Speichern von Benutzerereignissen, um sie später 
wieder abspielen zu können. Jedes Ereignis belegt acht Bytes (bzw. 6 Bytes auf PC-GEM) im 
Speicher. 

typedef struct 
{ 

LONG type; /* WORD auf PC-GEM! ! ! */ 

'LONG what; 

} APPLRECORD; 


Dabei gibt “type” die Art des Ereignisses an (siehe unter EVNT-Funktionen): 

0: Timer-Ereignis 
1: Button-Ereignis 

2: Maus-Ereignis 
3: Tastatur-Ereignis 

“what” enthält dann jeweils folgende Informationen: 


Timer-Ereignis: 

Button-Ereignis: 

Maus-Ereignis: 

Tastatur-Ereignis: 


Anzahl der verstrichenen Millisekunden 

Status der Maustaste im unteren Wort (0: nicht gedrückt, 1: gedrückt); 
Anzahl der Tastendrücke im oberen Wort. 

X-Koordinate (Oberes Wort), Y-Koordinate (Unteres Wort) 

Eingegebenes Zeichen (Unteres Wort), Tastaturstatus (Oberes Wort: 
K_RSHIFT (0x0001), KLSHIFT (0x0002), K_CTRL (0x0004), 
KALT (0x0008) 


Deklaration in C: 

WORD appl_trecord (APPLRECORD *tbuffer, WORD tlength) 

{ 

int_in[0] = tlength; 
addr_in[0] = tbuffer; 
return crys_if (15); 

} 
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GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

15 

Opcode für APPLJTRECORD 

contrl+2 

contrl[l] 

1 

# Einträge in int_in 

contrl+4 

contrl[2] 

1 

# Einträge in int_out 

contrl+6 

contrl(3] 

1 

# Einträge in addrjn 

contrl+8 

contrl [4] 

0 

# Einträge in addr_out 

int.Jn 

int_in[0] 

tlength 

addr_in 

addr_in[0] 

tbuffer 

int_out 

int_out[0] 

Return-Wert 


Parameter: 

lbuffer: 


tlength: 

appl_trecord(): 


Speicherbereich, in dem die Benutzerereignisse gespeichert werden 
(sollte wegen des Speicherformats achtmal bzw. sechsmal so groß wie 
count sein) 

Anzahl der zu speichernden Ereignisse 
Anzahl der gespeicherten Ereignisse 


Bemerkung 

Aufgrund eines Fehlers funktioniert diese Funktion erst ab GEM 1.2. 
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APPLBVSET (AES16) - nur in PC-GEM ab Version 2.0 


PC-GEM benötigt Informationen über die angeschlossenen logischen Laufwerke (für die 
Dateiauswahlbox). Mit “appl_bvset()” kann man die entsprechenden Informationen setzen. 

Deklaration in C: 

WORD appl_bvset (UWORD bvdisk, UWORD bvhard) 

( 

int_in[0] = bvdisk; 
int_in[l] = bvhard; 
return crys_if (16); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

16 

Opcode für APPL„BVSET 

contrl+2 

contrl[l] 

2 

# Einträge in int_in 

contrl+4 

contrl[2] 

1 

# Einträge in int_out 

contrl+6 

contrl[3] 

0 

# Einträge in addrjn 

contrl+8 

contrl [4] 

0 

# Einträge in addr_out 

int_in 

int_in[0] 

bvdisk 

int_in+2 

int_in[l] 

bvhard 

int_out 

int_out[0] 

Return-Wert 


Parameter: 

bvdisk: Bitvektor mit allen vorhandenen Disklaufwerken. Bit 15 (also das höchste Bit) 

steht für Laufwerk “A:”! 

bvhard: Bitvektor mit allen vorhandenen Harddisklaufwerken (Format wie zuvor) 
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1 APPL Y1ELD (AES 17) - nur in PC-GEM ab Version 2,0 


Kann benutzt werden, um andere AES-Prozesse ans Ruder zu lassen (genauer: Es wird ein 
AES-Prozeß-Switch erzwungen). 

Auf Atari-GEM-Versionen kann man statt dessen einen entsprechend kurzen Aufruf von 
*‘evnt_timer()” machen. 


Deklaration in C: 

WORD appl_yield (void) 

{ 

return crys_if(17); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

17 

Opcode für APPL_YIELD 

contrI+2 

contrl[l] 

0 

# Einträge in intjn 

contrl+4 

contrl [2] 

1 

# Einträge in int_out 

contrl+6 

contrl[3] 

0 

# Einträge in addrjin 

contrI+8 

contrl[4] 

0 

# Einträge in addr_out 

int_out 

int_out[0] 

Return-Wert 
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APPLEXIT (AES19) 


Mit “appLexitO” meldet sich ein Programm bei den AES ab. Die id des Programms wird 
wieder freigegeben und steht für andere Programme zur Verfügung. Außerdem wird instal¬ 
lierten Accessories eine AC_CLOSE-Mitteilung geschickt. 

Deklaration in C: 

WORD appl_exit (void) 

{ 

return crys_if (19); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

19 

Opcode für APPL_EXIT 

contrl+2 

contrl[l] 

0 

# Einträge in int_in 

contrl+4 

contrl[2] 

1 

# Einträge in irU.out 

contrl+6 

contrl[3] 

0 

# Einträge in addrjn 

contrl+8 

contrl [4] 

0 

# Einträge in addr_out 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 
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EVNT-Funktionen 


EVNT_KEYBD (AES 20) 


Wartet auf einen Tastendruck und gibt den entsprechenden Code zurück. Keyboard- 
Ereignisse werden übrigens immer nur der Applikation gemeldet, der das aktive Fenster gehört 
- also Vorsicht bei Accessories. 


Deklaration in C: 

WORD evnt__keybd (void) 

( 

return crys_if (20); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

20 

Opcode für EVNTJCEYBD 

contrl+2 

contrl[l] 

0 

# Einträge in int Jn 

contrl+4 

contrl[2] 

1 

# Einträge in int_out 

contrl+6 

contrl [3] 

0 

# Einträge in addrjn 

contrl+8 

contrl[4] 

0 

# Einträge in addr_out 

int_out 

int_out[0] 

Return-Wert 


Parameter: 

evnt_keybd(): Tastencode der gedrückten Taste 

(Bit 0..7: ASCH-Code, Bit 8..15: Scan-Code) 
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EVNTBUTTON (AES 21) 


Wartet auf ein festzulegendes Maustasten-Ereignis. 


Deklaration in C: 

WORD evht_button (WORD clicks, DWORD mask, UWORD state, WORD *pmx, 
WORD *pmy, WORD *pmb, WORD *pks) 

{ 

int_in[0] ~ clicks; 
int_in[l] = mask; 
int_in[2] = state; 
crys_if (21) ; 

*pmx = int_out[l]; 

*pmy = int_out[2]; 

*pmb = int_out[3]; 

*pks = int_out[4]; 
return int_out[0]; 

} 


GEM-Arrays: 


Adresse 

1 Feldelement 

Belegung 

contrl 

contrl [0] 

21 Opcode für EVNTJ3 UTf ON 

contrl+2 

contrl[l] 

3 # Einträge in int_in 

contrl+4 

contrl[2] 

5 # Einträge in int_out 

contrl+6 

contrl[3] 

0 # Einträge in addr_in 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

clicks 

int__in+2 

int_in[l] 

mask 

int_in+4 

int_in[2] 

state 

int_out 

int_out{0] 

Return-Wert 

int_out+2 

int_out[l] 

pmx 

int_out+4 

int_out[2] 

pmy 

int_out+6 

int_out[3] 

pmb 

int_out+8 

int_out[4] 

pks 
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Parameter: 

clicks: Anzahl der maximal gezählten Tastendrücke (2: Doppelklick etc.) 

mask: Maske für den gewünschten Mausknopf (Bit 0: linker Knopf, Bit 1: rechter 

Knopf) 

state: Erwünschter Status (Bitbelegung wie bei mask, ein Bit muß genau dann 

gesetzt sein, wenn der zugehörige Mausknopf gedrückt werden soll, um das 
Ereignis auszulösen) 

pmx: X-Koordinate des Mauszeigers bei Ereignisauslösung 

pmy: Y-Koordinate des Mauszeigers bei Ereignisauslösung 

pmb: Maustastenstatus (siehe state) 

pks: Tastaturzustand im Augenblick der Meldung des Ereignisses. Dabei gilt 

folgende Bitbelegung: 

K_RSHIFT (0x0001): rechte Shift-Taste 
KJLSHIFT (0x0002): linke Shift-Taste 
K_CTRL (0x0004): Control-Taste 

K„ALT (0x0008): Altemate-Taste 

evnt_button(): Anzahl der aufgetretenen Maustastendrücke (ist immer kleiner oder gleich 

clicks) 

Bemerkung 

Es ist nicht möglich, mittels “evnt_buttonQ” beide Maustasten gleichzeitig (und unabhängig 
voneinander) abzufragen! Ab PC-GEM/3 unterstützen die Event-Funktionen überhaupt nur 
noch eine (die linke) Maustaste. 
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E VNTMOUSE (AES 22) 


Wartet, bis der Mauszeiger einen rechteckigen Teil des Bildschirms betritt oder verläßt. 

Deklaration in C: 

WORD evnt_mouse (WORD flags, WORD x, WORD y, WORD width, 

WORD height, WORD *pmx, WORD *pmy, WORD *pmb, 
WORD *pks) 

{ 

int_in[0] = flags; 
int_in[l] = x; 
int_in[2] = y; 
int_in[3] = width; 
int_in[4] = height; 
crys_if (22); 

*pmx = int_out[1]; 

*pmy = int_out[2]; 

*pmb = int_out[3]; 

*pks = int__out [4]; 
return (int_out[0]); 

1 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

22 Opcode für EVNT_MOUSE 

contrl+2 

contrl[l] 

5 # Einträge in int_in 

contrl+4 

contrl[2] 

5 # Einträge in int_out 

contrl+6 

contrl[3] 

0 # Einträge in addr_in 

contrl+8 

contrl [4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

flags 

int_in+2 

int_in[l] 

X 

int_in+4 

int_in[2] 

y 

int_in+6 

int_in[3] 

width 

int_in+8 

int_in[4] 

height 
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Adresse 

Feldelement 

Belegung 

int_out 

int_out[0] 

Return-Wert (reserviert, immer 1) 

int_out+2 

int_out[l] 

pmx 

int_out+4 

int_out[2] 

pmy 

int_out+6 

int_out[3] 

pmb 

int_out+8 

int_out[4] 

pks 


Parameter: 


flags: 

x, y, width, height: 
pmx, pmy: 
pmb: 

pks: 


Betreten (0) oder Verlassen (1) des Rechtecks melden 

Rechteck-Koordinaten 

Position des Mauszeigers 

Tastenstatus beim Eintreten des Ereignisses (Bit 0: linker Mausknopf, 
Bit 1: rechter Mausknopf) 

Tastaturzustand im Augenblick der Meldung des Ereignisses. 

Dabei gilt folgende Bitbelegung: 

KJRSHIFT (0x0001): rechte Shift-Taste 

K_LSfflFT (0x0002): linke Shift-Taste 

K_CTRL (0x0004): Control-Taste 

K_ALT (0x0008): Altemate-Taste 
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EVNT_MESAG (AES 23) 


Wartet, bis im Ereignispuffer eine Meldung (Message) vorliegt. 

Deklaration in C: 

WORD evnt__mesag {WORD *pbuf£) 

{ 

addr_in[0] = pbuff; 
return crys_if (23); 

} 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

23 

Opcode für EVNT_MESAG 

contrl+2 

contrl[l] 

0 

# Einträge in int_in 

contrl+4 

contrl[2] 

1 

# Einträge in int_out 

contrl+6 

contrl[3] 

1 

# Einträge in addrjn 

contrl+8 

contrl[4] 

0 

# Einträge in addr_out 

int_out 

int_out[0] 

Return-Wert (reserviert, immer 1) 

addrjn 

addrjn [0] 

pbuff 



Parameter: 

pbuff: Adresse des Speichers für die erwartete Message (Länge: 16 Bytes) 
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EVNT TIMER (AES 24) 


Wartet, bis die in Millisekunden anzugebende Zeit verstrichen ist. Man sollte in Programmen 
niemals “irgendwelche” Warteschleifen benutzen, sondern immer nur diese (so kann nämlich 
in der Zwischenzeit beispielsweise einem Accessory Prozessorzeit zugewiesen werden). 


Deklaration in C: 

WORD evnt_timer (UWORD locnt, UWORD hi ent) 
{ 

int_in[0] = locnt; 
int_in[l] = hient; 
return (crys__if (24)); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

24 Opcode für EVNTJTIMER 

contrl+2 

contrl [1] 

2 # Einträge in int_in 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

0 # Einträge in addtrjn 

contrl+8 

contrl [4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

locnt 

intJn+2 

int_in[l] 

hient 

int_out 

int_out[0] 

Return-Wert (reserviert, immer 1) 


Parameter: 

locnt, hient: Low- und High-Word der Anzahl von Millisekunden 
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Wartet auf eine Kombination verschiedener Ereignisse. Vorsicht - es kann mehr als ein 
Ereignis gleichzeitig auftreten! 


Deklaration in C: 

WORD evntjnulti (UWORD flags, UWORD bclk, DWORD bmsk, UWORD bst, 
UWORD mlflags, UWORD mix, UWORD mly, UWORD mlw, 
UWORD mlh, UWORD m2flags, UWORD m2x, DWORD m2y, 
DWORD m2w, DWORD m2h, WORD *mepbuff, UWORD tlc, 
UWORD thc, UWORD *pmx, UWORD *pmy, WORD *pmb, 
WORD *pks, UWORD *pkr, WORD *pbr) 

1 

int_in[0] = flags; 
int_in[l] = bclk; 
int_in[2] = bmsk; 
int_in[3] = bst; 
int_in[4] = mlflags; 
int_in[5] = mix; 
int_in[6] = mly; 
int_in[7] = mlw; 
int_in[8] = mlh; 
int_in[9] = m2flags; 
int_in[10] = m2x; 
int_in[ll] = m2y; 
int_in[12] = rr\2w; 
int_in[13] = m2h; 
addr_in[0] = mepbuff; 
int__in[14] = tlc; 
int_in[15] = thc ; 
crys_if (25); 

*pmx = int_out[l]; 

*pmy = int_out[2]; 

*pirib = int_out [3] ; 

*pks = int__out[4]; 

*pkr = int_out[5]; 

*pbr = int_out[6]; 
return int out [0]; 


} 
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GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

25 Opcode für EVNT_MULTI 

contrl+2 

contrlfl] 

16 # Einträge in int_in 

contrl+4 

contrl [2] 

7 # Einträge in mt_out 

contrl+6 

contrl[3] 

1 # Einträge in addrjn 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

intjn 

int_in[0] 

flags 

int_in+2 

int_in[l] 

bclk 

intJn+4 

int_in[2) 

bmsk 

intJn+6 

intjn[3] 

bst 

intJn+8 

int_in[4] 

mlflags 

int_in+10 

int_in[5] 

mix 

int_in+12 

int_in[6] 

mly 

intjn+14 

int_in[71 

mlw 

int_in+16 

int_in[8] 

mlh 

int_in+18 

int_in[9] 

m2flags 

int_Jn+20 

int_in[10] 

m2x 

int_in+22 

int_in[ll] 

m2y 

intJn+24 

int_in[12] 

m2w 

intJn+26 

int_in[13] 

m2h 

intJn+28 

int_in[14] 

Üc 

int_in+30 

intjn[15] 

thc 

int_out 

int_out[0] 

Return-Wert 

int_out+2 

int_out[l] 

pmx 

int_out+4 

int_out[2] 

pmy 

int_out+6 

int_out[3] 

pmb 

int_out+8 

int_out[4] 

pks 

int_out+10 

int_out[5] 

pkr 

int_out+12 

int_out[6J 

pbr 

addrjn 

addr_in[0] 

mepbuff 


Parameter: 

Die meisten Parameter ergeben sich direkt aus der Definition von “evnt_mouse()”, 
“evntJceybdO”, “evnt_button()” und “evntjnesagO”. Man beachte dabei, daß man auf zwei 
verschiedene Maus-Ereignisse (mlflags und m2flags etc.) prüfen kann. 
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Alle weiteren Parameter: 

flags: Legt fest, auf was für ein Ereignis die Applikation warten soll. Die Bedeutung 

der einzelnen Bits: 

Bit 0: MUJKEYBD (0x0001) (Tastaturereignis) 

Bit 1: MU_BUTTON (0x0002) (Mausknopfereignis) 

Bit 2: MU_M1 (0x0004) (erstes Mausereignis) 

Bit 3: MU_M2 (0x0008) (zweites Mausereignis) 

Bit 4: MU_MESAG (0x0010) (Mitteilungs-Ereignis) 

Bit 5: MUTIMER (0x0020) (Timer-Ereignis) 
evnt_multi(): Die Ereignisse, die tatsächlich eingetreten sind. Bitbelegung wie bei flags. 

Bemerkungen 

“pmx”, “pmy”, “pmb” und “pks” werden immer - ungeachtet “flags” - zurückgeliefert. Die 
zurückgelieferten Werte spiegeln jeweils den Zustand bei Abfrage des Ereignisses wieder. 

Durch die unglaubliche Parameterzahl verbraucht ein Aufruf von “evnt_multi()” beträchtlich 
Prozessorzeit. Man denke daran, daß zunächst alle Parameter auf den Stack gepackt und dann 
auf die Eingabearrays verteilt werden. Genau dasselbe passiert dann noch mal intern in den 
AES. Erschwerend kommt hinzu, daß man meistens viele Parameter gar nicht setzen will. 

Das hat mittlerweile auch Digital Research erkannt: Im GEM/3-Toolkit findet man daher die 
folgende Alternative, bei der man nur einen Zeiger auf eine “MEVENT’-Struktur übergibt. 

typedef struct 
{ 

WORD g_x, g_y, g_w, g_h; 

} GRECT; 

typedef struct 
{ 

UWORD e_flags; 

UWORD e_bclk; 

UWORD e_bmsk; 

UWORD e_bst; 

UWORD e_mlflags; 

GRECT e_ml; 

UWORD e_m2 flags; 

GRECT e_m2 ; 

WORD *e_mepbuf; 

ULONG e time; 
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WORD 

e mx; 

WORD 

e_ray; 

UWORD 

ejnb; 

UWORD 

e__ks; 

UWORD 

e_kr; 

UWORD 

e_br; 

UWORD 

e__m3flags; 

GRECT 

e_m3; 

WORD 

e_xtraO; 

WORD 

*e_smepbu£ 

ULONG 

e_xtral; 

ULONG 

e__xtra2; 


} MEVENT; 

WORD evnt_event (MEVENT *pmevent) 

{ 

inemcpy {int_in, pinevent, 14 * sizeof (UWORD)) ; 
addr_in[0] = pmevent->e_mepbuf; 
int_in[14] = (WORD) ((pmevent->e_time) OxFFFF); 
int_in[15] = (WORD) (<pmevent->e_time) » 16); 
crys_if (25); 

memcpy (&(pmevent->e_rax ), &(int_out[1]), 6 * sizeof (UWORD)); 
return int_out[0]; 

} 
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j EVNT DCLICK (AES 26) 


Setzt die Geschwindigkeit für das “Doppelklicken” der Maus oder stellt den aktuellen Wert 
ein. 


Deklaration in C: 

WORD evnt_dclick (WORD rate, WORD setit) 
{ 

int__in[0] = rate; 
int_in[l] = setit; 
return crys_if (26); 

) 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

26 Opcode für EVNT_DCLICK 

contrl+2 

contrI[l] 

2 # Einträge in int_in 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrl [3] 

0 # Einträge in addrjn 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

rate 

int_in+2 

int_in[l] 

setit 

int_out 

int_out[0] 

Return-Wert 


Parameter: 

rate: Neue Geschwindigkeit für Doppelklicks (0..4) 

setit: 0: aktuellen Wert feststellen und rate ignorieren 

1: neuen Wert setzen 

evnt_dclick: jetzt gültige Geschwindigkeit (unabhängig von setit) 
Bemerkungen 

In älteren GEM-Dokumentationen auch häufig “evnt_dclicks()” genannt. 
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MENU-Funktionen 


MENUBAR (AES 30) 


Setzt oder desaktiviert die Menüleiste eines Menüobjektbaums. Auf gar keinen Fall vor Been¬ 
digung des Programms vergessen! 

Deklaration in C: 

WORD menu__bar (OBJECT *tree, WORD showit) 

{ 

addr__in[Q] ~ tree; 
int__in[0] = showit; 
return crys___if (30) ; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

30 

Opcode für MENU_BAR 

contrl+2 

contrlfl] 

1 

# Einträge in intjn 

contrl+4 

contrl [2] 

1 

# Einträge in int_out 

contrl+6 

contrl[3] 

1 

# Einträge in addrjn 

contrl+8 

contrl[4] 

0 

# Einträge in addr_out 

intjn 

int_infO] 

showit 

addrjn 

addrjn[0] 

tree 


int_out 

int_out[0] 

Return-Wert (0: Fehler) 


Parameter: 

showit: 0: Menüleiste löschen 

1: Menüleiste setzen 

tree: Anfangsadresse des Objektbaumes des Menüs 
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MENUJCHECK (AES 31) 


Löscht oder setzt ein Häkchen vor einem Menüeintrag (dazu sollte man jeden Eintrag mit zwei 
Leerzeichen beginnen). Ab PC-GEM 2.0 gibt es statt dessen kleine Pfeilspitzen (Dreiecke). 

Deklaration in C: 

WORD menu_icheck (OBJECT *tree, WORD itemnum, WORD checkit) 

{ 

addr_in[0] = tree; 
int_in[0] = itemnum; 
int_in[lj = checkit; 
return crys__if (31); 

) 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

31 Opcode für MENUJCHECK 

contrl+2 

contrl[l] 

2 # Einträge in intjn 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

1 # Einträge in addr Jn 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

itemnum 

intJn+2 

int_in[l] 

checkit 

addrjn 

addr_in[0] 

tree 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 


Parameter: 

itemnum: Objektnummer des betreffenden Menüeintrags 

checkit: 0: Häkchen löschen 

1: Häkchen setzen 

tree: Anfangsadresse des Menü-Objektbaums 
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MENU JENABLE (AES 32) 


Schaltet Meniieinträge ein und aus (gekennzeichnet durch graue Schattierung). 


Deklaration in C: 

WORD menu_ienable (OBJECT *tree, WORD itemnum, WORD enableit) 
{ 

addr_in[0) = tree; 
int_in[0] ~ itemnum; 
int_in[l] = enableit; 
return crys_if (32); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl(O) 

32 Opcode für MENU JENABLE 

contrl+2 

contrl[l] 

2 # Einträge in intjn 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

1 # Einträge in addrjn 

contrl+S 

contrl[4] 

0 # Einträge in addr__out 

int_in 

int_in[0] 

itemnum 

int_in+2 

int_in[l] 

enableit 

addr_in 

addr_in[0] 

tree 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 


Parameter: 

itemnum: Objektnummer des zu bearbeitenden Menüeintrags 

enableit: 0: desaktivieren, 1: aktivieren 

tree: Anfangsadresse des Menü-Objektbaums 
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MENUTNORMAL (AES 33) 

Invertiert Menütitel. 


Deklaration in C: 

WORD menu_tnormal (OBJECT *tree, WORD titlenum, WORD norraalit) 
{ 

addr_in[0] = tree; 
int_in[0] = titlenum; 
int_in[l] = normalit; 
return crys_if (33); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

33 

Opcode für MENUJTNORMAL 

contrl+2 

contrl[l] 

2 

# Einträge in int_in 

contrl+4 

contrl [2] 

1 

# Einträge in int_out 

contrl+6 

contrl [3] 

1 

# Einträge in addrjn 

contrl+8 

contrl [4] 

0 

# Einträge in addr_out 

intjn 

int_in[0] 

titlenum 

int_in+2 

int_in[l] 

normalit 

addrjn 

addr_in[0] 

tree 


int_out 

int_out[0] 

| Retum-Wert (0: Fehler) 


Parameter: 

titlenum: Objektnummer des Menütitels 

normalit: 0: invers darstellen 

1: normal darstellen 

tree: Anfangsadresse des Menü-Objektbaums 
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MENUTEXT (AES 34) 


Ändert den Text in einem Menüeintrag. Damit hat man die Möglichkeit, Texte in Menüs vom 
momentanen Zustand eines Programms abhängig zu machen (“kontext-sensitiv”). 

Accessories können diese Methode natürlich nicht benutzen, da sie die Adresse des aktiven 
Menübaums nicht kennen. Statt dessen muß man also von Beginn an genug Platz für den 
Menüeintrag freihalten und dann den entsprechenden Text an die entsprechende Adresse 
kopieren. 


Deklaration in C: 

WORD menu_text (OBJECT *tree, WORD inum, CHAR *ptext) 
{ 

addr__in[0] =• tree; 
int_in [ 0] = inum; 
addr_in[l] = ptext; 
return crys_if (34); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

34 Opcode für MENUJTEXT 

contrl+2 

contrl[l) 

1 # Einträge in intjn 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

2 # Einträge in addrjn 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

inum 

addrjn 

addrjn[0] 

tree 

addr_in+4 

addr_in[l] 

ptext 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 


Parameter: 

item: Objektnummer des zu ändernden Menüeintrags 
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text: Anfangsadresse des neuen Eintrags (GEM benutzt nur den Zeiger, legt also keine 
Kopie an!). Sollte nicht länger als der bisherige Eintrag sein, 
tree: Anfangsadresse des Menü-Objektbaums 

Bemerkungen 

Ab PC-GEM 2.0 legen die AES eine Kopie des Menü-Objektbaums an. Daher muß man nach 
jeder Änderung eines Eintrags das Menü mittels “menu_bar()” neu auf den Bildschirm 
bringen! Für Accessories hat man sich gezwungenermaßen einen Ausweg einfallen lassen: Sie 
können in “tree” anstelle der (unbekannten) Baumadresse die Nummer des Accessory- 
Eintrags (Rückgabewert von “menujregisterO”) übergeben (dazu setzt man das obere Wort 
auf Null und übergibt im unteren Wort die Nummer des Eintrags). 
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MENUREGISTER (AES 35) 

Trägt Namen im ersten Drop-Down-Menü für Accessories ein. Insgesamt sechs quasi gleich¬ 
zeitig laufende Accessories können gemeinsam sechs Einträge im Menü benutzen. 

Deklaration in C: 

WORD menu_register (WORD pid, const CHAR *pstr) 

{ 

int_in[0] = pid; 
addr_in[0] = pstr; 
return crys_if (35) ; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

35 Opcode für MENU_REGISTER 

contrl+2 

contrl[l] 

1 # Einträge in int_in 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

1 # Einträge in addrjn 

contrl+8 

contrl [4] 

0 # Einträge in addr_out 

intjn 

int_in[0] 

pid 

addr_in 

addr_in[0] 

pstr 

int_out 

int_out[0] 

Return-Wert 


Parameter; 

pid: Identifikation des Accessories (ap_id) 

pstr: Anfangsadresse des Textes für den Menüeintrag (GEM benutzt nur den 

Zeiger, legt also keine Kopie an) 

menu_register(): Menü-Kennung für das Accessory oder -1, falls kein Platz für weitere 
Einträge ist 

Bemerkungen 

Ein Aufruf von “menu_register(>” wirkt sich erst dann aus, wenn das jeweilige Hauptprogramm 
einen Aufruf von “menu_bar()” macht. Daher sollte man bei Accessories gleich nach Start den 
Eintrag vornehmen - sonst verpaßt man nämlich den “menu_bar()”-Aufruf des Desktops. 
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MENU UNREGISTER (AES 36) - nur in PG-GEM ab Version 2.0 


Ab PC-GEM 2.0 können Accessories ihren Namen wieder aus dem Desk-Menü entfernen. 


Deklaration in C: 

WORD menu_unregister (WORD mid) 

{ 

int_in[0] = mid; 
return crys__if (36); - 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

36 

Opcode für MENU_UNREGISTER 

contrl+2 

contrl[l] 

1 

# Einträge in int_in 

contrl+4 

contrl[2] 

1 

# Einträge in int_out 

contrl+6 

contrl [3] 

0 

# Einträge in addrjn 

contrl+8 

contrl[4] 

0 

# Einträge in addr_out 

intjn 

int_in[0] 

mid 


int_out 

int_out[0] 

Return-Wert (0: Fehler) 


Parameter: 

mid: Identifikation des Accessories (ap_id) 
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MENU CLICK (AES 37) - nur in PC-GEM/3 


Ab PC-GEM/3 kann man die Behandlung der Drop-Down-Menüs auf “Pull-Down” umstel¬ 
len. 


Deklaration in C: 

WORD menu_click (WORD click, WORD setit) 
{ 

int_in(0] = click; 
int_in[1] = setit; 
return crys_if (37); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

37 Opcode für MENU_CLICK 

contrl+2 

contrl [1] 

2 # Einträge in intJn 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

0 # Einträge in addrjn 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

intjin 

int_in[0] 

click 

int_in+2 

int_in[l] 

setit 

int_out 

int_out[0] 

Retum-Wert 


Parameter: 

click: 0: Dropdown, 1: Pulldown 

setit: 0: abffagen, 1: setzen 

menu_click(): 0: Dropdown, 1: Pulldown 






628 


ATARI Profibuch 


OBJC-Funktionen 


OBJCADD (AES 40) 


Stellt die hierarchische Verknüpfung zwischen zwei Objekten in einem Objektbaum her. 
Deklaration in C: 

WORD objc_add (OBJECT *tree, WORD parent, WORD child) 

{ 

addr_in[0] = tree; 
int_in[0] = parent; 
int_in[l] = child; 
return crys_if (40) ; 

1 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

40 Opcode für OBJC_ADD 

contrl+2 

contrl[l] 

2 # Einträge in int_in 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

1 # Einträge in addr_in 

contrl+8 

contrl [4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

parent 

int_in+2 

int_in[l] 

child 

addr_in 

addr_in[0] 

tree 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 


Parameter: 

parent: Objektnummer des Objekts, zu dem das Child hinzugefügt werden soll 

child: Objektnummer des hinzuzufügenden Objekts (“objhead” und “objail” müs¬ 

sen bereits passend initialisiert sein), 
tree: Adresse des Objektbaumes 
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OBJC_DELETE (AES 41) 


Löst ein Objekt aus der Liste des Objektbaumes. 
Deklaration in C: 

WORD objc_delete (OBJECT *tree, WORD delob) 
{ 

addr_in[0] = tree; 
int_in[0] = delob; 
return crys_if (41); 

} 


GEM-Arrays: 


Adresse 

| Feldelement 

Belegung 

contrl 

contrl(0] 

41 Opcode für OBJCJDELETE 

contrl+2 

contrlfl] 

1 # Einträge in int_in 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

1 # Einträge in addr_in 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

int_in 

int_in(0] 

delob 

addr_in 

addr_in[0] 

tree 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 


Parameter: 

delob: Objektnummer des herauszulösenden Objekts 
tree: Anfangsadresse des Objektbaums 
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OBJCJDRAW (AES 42) 


Stellt ganze Objekte oder Teile von Objekten auf dem Bildschirm dar. Dabei kann zusätzlich 
ein Bildschirmausschnitt in Koordinaten angegeben werden, auf den die Darstellung be¬ 
schränkt wird. Dies ist beispielsweise beim Wiederherstellen von Bildausschnitten, die von 
einem Fenster überlagert wurden, nützlich. 

Deklaration in C: 

WORD objcjdraw (OBJECT *tree, WORD drawob, WORD depth, WORD xc, 

WORD yc, WORD wc, WORD hc) 

{ 

addr_in[0] = tree; 
int_in[0] = drawob; 
int_in[l] = depth; 
int_in[2] = xc; 
int_in[3] = yc; 
int_in[4] = wc; 
int_±n[5] = hc; 
return crys_if (42); 

) 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

42 Opcode für OBJC_DRAW 

contrl+2 

contrl[l] 

6 # Einträge in intjn 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrl [3] 

1 # Einträge in addr_in 

contrI+8 

contrl[4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

drawob 

int_in+2 

int_in[l] 

depth 

int_in+4 

int_in[2] 

xc 

int_in+6 

int_in[3] 

yc 

int_in+8 

int_in[4] 

wc 

int_in+10 

int_in[5] 

hc 

addr_in 

addr_in[0] 

tree 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 
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Parameter: 

drawob: Objektnummer des ersten zu zeichnenden Objekts 

depth: Anzahl der zu zeichnenden Objekt-Ebenen (0: nur das erste Objekt) 

xc, yc, 

wc, hc: Position und Maße des begrenzenden (clipping) Rechtecks 

tree: Anfangsadresse des betreffenden Objektbaums 
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OB JCFIND (AES 43) 

Ermittelt, über welchem Objekt sich der Mauszeiger befindet (oder allgemeiner: welches 
Objekt an einer gegebenen Bildschirmposition steht). 

Deklaration in C: 

WORD objc_find (OBJECT *tree, WORD startob, WORD depth, WORD mx, 

WORD my) 

( 

addr_in[0] = tree; 
int_in[0] = startob; 
int_in[l] = depth; 
int_in[2] = mx; 
int_in[3] = my; 
return crys_if (43); 

1 

GEM-Arrays: 

Adresse | Feldelement | Belegung 

Opcode für OBJC_FlND 

# Einträge in int_in 

# Einträge in int_out 

# Einträge in addr_in 

# Einträge in addr_out 


addr_in addr_in[0] tree 

int_out int_out[0] Return-Wert (-1: nichts gefunden) 

Parameter: 

startob: Objektnummer des Objekts, bei dem die Suche beginnen soll 


contrl contrl[0] 43 

contrl+2 contrl[l] 4 

contrl+4 contrl [2] 1 

contrl+6 contrl[3] 1 

contrl+8 contrl[4] 0 

int_in int_in[0] startob 

int„in+2 int_in[l] depth 

int_in+4 int_in[2] mx 

int_in+6 int_in[3] my 





AES-Betriebssystemroutinen 


633 


depth: 

mx,my: 

free: 

objc_find(): 


Anzahl der Ebenen in der Objekthierarchie, die durchsucht werden sollen (0: 
nur Mutterobjekt) 

Koordinaten der betreffenden Bildschirmposition 
Anfangsadresse des zu untersuchenden Objektbaums 
Objektnummer des gefundenen Objekts 
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OBJCOFFSET (AES 44) 


Berechnet die Position eines Objekts in absoluten Bildschirmkoordinaten. 

Deklaration in C: 

WORD objc_offset (OBJECT *tree, WORD obj, WORD *poffx, WORD *poffy) 

{ 

addr_in[0] = tree; 
int_in[0] = obj; 
crys_if (44); 

*poffx = int_out[l]; 

*pof fy = int^out [2]; 
return int_out[0]; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

44 Opcode für OBJCOFFSET 

contrl+2 

contrl[l] 

1 # Einträge in int_in 

contrl+4 

contrl[2] 

3 # Einträge in int_out 

contrl+6 

contrl[3] 

1 # Einträge in addrjn 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

intjn 

int_in[0] 

obj 

addr_in 

addr_in[0] 

tree 

int_out 

int_out[0] 

Retum-Wert (0: Fehler) 

int_out+2 

int„out[l] 

poffx 

int_out+4 

int_out[2] 

poffy 


Parameter: 

obj: Objektnummer des betreffenden Objekts 

tree: Anfangsadresse des Objektbaums 

poffx, poffy: die berechneten Koordinaten 
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|~ OBJC ORDER (AES 45) 


Die Position eines Objekts innerhalb eines Unterbaums wird geändert. 


Deklaration in C: 

WORD objc_order (OBJECT *tree, WORD movjobj, WORD newpos) 

{ 

addr_in[0] = tree; 
int_in[0] = mov_obj; 
int_in[l] = newpos; 
return crys_if (45); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

1 ' 

45 Opcode für OBJC.ORDER 

contrl+2 

contrlfl] 

1 2 # Einträge in int_in 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

1 # Einträge in addrjn 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

intjn 

int_in[0] 

mov_obj 

int_in+2 

int_in(l] 

newpos 

addr_in 

addr_in[0] ' 

tree 

int_out 

int_out[0] 

Return-Wert (0; Fehler) 


Parameter; 


mov_obj: 

newpos; 


tree; 


Objektnummer des betreffenden Objekts 
0: an den Anfang 

1: an zweite Stelle 

2: an dritte Stelle (usw.) 

-1: an das Ende 

Anfangsadresse des Objektbaums 
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OBJCEDIT (AES 46) 


Erlaubt Texteingaben in Objekte vom Typ GJFTEXT oder G_FBOXTEXT. 


Deklaration in C: 


WORD objc_edit (OBJECT *tree, WORD obj, WORD inchar, WORD *idx, 
WORD kind) 


{ 

addr_in[0] = t ree; 
int_in[0] = obj; 
int_in[l] = inchar; 
int_in[2] = *idx; 
int_in[3] = kind; 
crys_if (46); 

*idx = int out[l]; 
return int^out[0]; 

} 


GEM-Arrays; 


Adresse 

Feldelement 

contrl 

contrl[0] 

contrl+2 

contrl[l] 

contrl+4 

contrl[2] 

contrl+6 

contrl[3] 

contrl+8 

contrl[4] 

int_in 

int_in[0] 

int_in+2 

int_in[l] 

int_in+4 

int_in[2] 

int_in+6 

int_in[3] 

addr„in 

addr_in[0] 

int.out 

int_out[0] 

int_out+2 

int_out[l] 


Belegung 


46 Opcode für OBJC_EDIT 
4 # Einträge in int_in 

2 # Einträge in int_out 

1 # Einträge in addr_in 

0 # Einträge in addr_out 

obj 

inchar 

Inhalt von idx 
kind 

tree 

Return-Wert (0: Fehler) 
idx 
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Parameter: 


obj: 

inchar: 

idx: 

kind: 


Nummer des zu editierenden Objekts 
Eingegebenes Zeichen 
Position des Zeichens im String 
Funktionsauswahl: 


ED_START (0): 
DJNTT(l): 

ED_CHAR (2): 

ED_END (3): 


reserviert 

Berechne aus te_ptext und te_.ptmplt einen formatierten 
String und schalte Cursor ein 

Betreffendes Zeichen verarbeiten und den String neu 
anzeigen 

Cursor ausschalten 


Bemerkungen 

Vorsicht! Bei dem hier angegebenen Binding wird davon ausgegangen, daß man für int_in[2] 
dieselbe Variable wie für int_out[l] verwendet - genauso sieht es auch in den Bibliotheken 
von DR und Megamax aus. In der ursprünglichen GEM-Dokumentation von DR hingegen 
waren dafür verschiedene Variablen angegeben. Der Aufruf lautete also: 


objc_edit (tree, obj, inchar, idx, kind, sidx); 

Möglicherweise existieren AES-Bibliotheken, bei denen “objc editO” noch immer auf diese 
Weise eingebunden ist! 
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! OBJC CHANGE (AES 47) 


Ändert den Status (ob_state) eines Objekts und zeichnet es gegebenenfalls neu, sofern es sich 
innerhalb eines gegebenen Begrenzungsrechtecks (clipping rectangle) befindet. 

Deklaration in C: 

WORD objc_change (OBJECT *tree, WORD drawob, WORD resvd, WORD xc, 
WORD yc, WORD wc, WORD hc, WORD newstate, 

WORD redraw) 

{ 

addr_in[0] =; tree; 
int_in[0] = drawob; 
int_in[l] = resvd; 
int_in[2] = xc; 
int_in[3] = yc; 
int_in[4] = wc; 
int_in[5] = hc; 
int_in[6] = newstate; 
int_in[7] = redraw; 
return crys_if (47); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrlfO] 

47 Opcode für OBJC_CHANGE 

contrl+2 

contrl[l] 

8 # Einträge in int_in 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

1 # Einträge in addrjn 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

intjn 

int_in[0] 

drawob 

int_in+2 

int_in[l] 

resvd 

int_in+4 

int_in[2] 

xc 

int_in+6 

int_in[3] 

yc 

int_in+8 

int_in[4] 

WC 

int_in+10 

int_in[5] 

hc 

int_in+I2 

int_in[6] 

newstate 
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Adresse 

Feldelement 

Belegung 

int_in+14 

int_in[7] 

redraw 

addrjn 

addr_in[0] 

tree 

int_out 

int_out[0] 

Return -Wert (0: Fehler) 


Parameter: 


drawob: 
resvd: 
xc, yc, 
wc, hc: 
newstate: 
redraw: 

tree: 


Objektnummer des betreffenden Objekts 
Reserviert; muß 0 sein 

Koordinaten des begrenzenden Rechtecks 
Neuer Status (ob_state) des Objekts 
0: Objekt nicht neu zeichnen 
1: Objekt neu zeichnen 
Anfangsadresse des Objektbaums 


Bemerkung 

In neueren Bindings wird das resvd-Feld auch häufig ausgelassen und automatisch auf Null 
gesetzt. 
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FORM-Funktionen 

FORMDO (AES 50) 

Dies ist die zentrale Routine im Dialog-Manager. Sie übernimmt die komplette Verwaltung 
eines Formular-Objektes, bis der Benutzer ein Objekt mit EXTT- oder TOUCHEXIT-Status 
anklickt. 

Deklaration in C: 

WORD form_do (OBJECT *form, WORD Start) 

{ 

addr_in(0] = form; 
int_in[0] — Start; 
return crys if (50) ; 

} 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

50 Opcode für FORM_DO 

contrl+2 

contrl[l] 

1 # Einträge in int_in 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrl [3] 

1 # Einträge in addrjn 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

Start 

addrjn 

addrjn[0] 

form 

int_out 

int_out[0] 

Retum-Wert 


Parameter: 

Start: Nummer des ersten zu editierenden Objekts im Baum (oder Null) 

form: Adresse des Objektbaums 

form_do(): Nummer des Objekts, das der Benutzer zur Beendigung angeklickt hat (bei 
Doppelklick auf TOUCHEXIT-Objekten wird Bit 15 gesetzt). 
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FORMDIAL (AES 51) 


“FMD_START” reserviert einen Bildschirmausschnitt, Dies hat normalerweise keine weitere 
Auswirkung, wird aber häufig von “Bildschirmbeschleunigem” benutzt, um den belegten 
Bildschirmausschnitt in einen Puffer zu kopieren. Daher auf gar keinen Fall weglassen! 

“FMD_GROW” zeichnet eine Reihe von sich ausdehnenden Rechtecken. Man sollte diese 
Funktion nicht überstrapazieren, nur selten ist sie wirklich sinnvoll. Ihr Sinn und Zweck 
besteht darin, dem Benutzer zusätzliche Infonnationen darzubieten - zum Beispiel wenn ein 
selektiertes Objekt per Tastaturkürzel “geöffnet” wird. 

Im Zweifelsfall sollte man eine Option anbieten, diese Funktion auszulassen: Geübte Benutzer 
werden es einem danken. 

“FMD_SHR1NK” ist das Gegenstück zu “FMDJ3ROW” (schrumpfende Rechtecke). 

“FMD_FINISH” gibt den durch “FMD_START” reservierten Bildausschnitt wieder frei. In 
der Realität heißt das: GEM sorgt dafür, daß alle betroffenen Fensterinhalte wieder restauriert 
werden (das heißt allerdings auch: Das Rechteck muß vollständig innerhalb des Arbeitsbereichs 
von Fenster 0 liegen). Dazu verschickt es an alle betroffenen AES-Prozesse entsprechende 
WM_REDR A W -Mitteilungen. 


Deklaration in C: 


WORD form_dial (WORD flag, WORD littlx, 
WORD littlh, WORD bigx, 
WORD bigh) 


{ 


int_in[0] 
int_in[1] 
int_in[2] 
int__in[3] 
int_in[4 ] 
int_in[5] 
int_in[6] 
int_in[7] 
int in[8] 


flag; 

littlx; 

littly; 

littlw; 

littlh; 

bigx; 

bigy; 

bigw; 

bigh; 


return crys_if (51); 


WORD littly, WORD littlw, 
WORD bigy, WORD bigw, 
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GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

51 Opcode für FORM_DIAL 

contrl+2 

contrl[l] 

9 # Einträge in intjn 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

eontrl[3] 

0 # Einträge in addr_in 

contrl+8 

contrl [4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

flag 

int_in+2 

int_in[l] 

littlx 

intJn+4 

int_in[2] 

littly 

int_in+6 

int_in[3] 

littlw 

int_in+8 

int_in[4] 

littlh 

int_in+10 

int_in[5] 

bigx 

int_in+12 

int_in[6] 

bigy 

int_in+14 

int„in[7] 

bigw 

int_in+16 

int_in[8] 

bigh 

int_out 

int_out[0] 

Retum-Wert (0: Fehler) 


Parameter: 

flag: Typ der FORM_DIAL-Funktion: 

FMD_START (0): Reserviert Bildschirmbereich für Dialogbox. 

FMD_GROW (1): Zeichnet sich ausdehnendes Rechteck. 

FMD_SHRJNK (2): Zeichnet schrumpfendes Rechteck. 

FMD_FINISH (3): Gibt Bildschirmbereich wieder frei, 
litt!...: Koordinaten für Rechteck in seiner kleinsten Größe 
big...: Koordinaten für Rechteck in seiner größten Ausdehnung 

Bemerkungen 

Die Subfunktionen “FMD_GRO W” und “FMDJ3HRINK” sind übrigens inPC-GEM 2.0 dem 
Rechtsstreit zwischen Digitial Research und Apple zum Opfer gefallen! 

“FMD_FINISH” wird gern dazu benutzt, um einen Bildschirmneuaufbau auszulösen. Aber 
Vorsicht : Die Menüleiste (die außerhalb des Arbeitsbereichs von Fenster 0 liegt) kann man 
so nicht restaurieren! 
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FORM ALERT (AES 52) 


Stellt eine Alarmbox (Alertbox) auf dem Bildschirm dar. 

“form_alert()” ist kein Ersatz für eine Dialogbox und sollte ausschließlich für kurze Informa¬ 
tionen und Fehlermeldungen eingesetzt werden. Dabei sollte man die verschiedenen Symbole 
folgendermaßen benutzen: 

Das Ausrufezeichen (“NOTE”) steht für eine kurze Meldung, die der Benutzer nur bestätigen 
soll. Das könnte ein Sicherheitshinweis, aber auch eine Benachrichtigung über einen abge¬ 
schlossenen Arbeitsgang sein. 

Das Fragezeichen (“WAIT”) dient für Sicherheitsabfragen, bevor ein bestimmter Vorgang 
(wie zum Beispiel das Formatieren einer Diskette) durchgeführt wird. 

Das Stopschild (“STOP”) ist angebracht, wenn ein ernsthaftes Problem aufgetreten ist, das der 
Benutzer unbedingt zur Kenntnis nehmen muß. 

Deklaration in C: 

WORD form_alert (WORD defbut, const CBAR *astring) 

{ 

int_in[0J = defbut; 
addr_in[0] = astring; 
return crys__if (52); 

} 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

52 Opcode für FORM_ALERT 

contrl+2 

contrl[l] 

1 # Einträge in int_in 

contrl+4 

contrl [2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

1 # Einträge in addrjn 

contrl+8 

contrl [4] 

0 # Einträge in addr_out 

int_in 

intJnfO] 

defbut 

addrjn 

addrjn[0] 

astring 

int_out 

int_out[0] 

Return-Wert 
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Parameter: 

defbut: 

astring: 


form_alert(); 


Nummer des Default-Knopfes (0: keiner, 1: erster etc.) 

Adresse des Strings mit den Daten für die Alertbox. 

Format: “[<Icon>][<Text>][<Buttons>]”, wobei <Icon>: 

N0_IC0N (0): kein Icon 
NOTE (I) 

WATT (2) 

STOP (3) 

<Text>: maximal fünf Textzeilen mit max. 30 Zeichen, untereinander 

durch >l< getrennt 

<Buttons>: bis zu drei durch >l< getrennte Button-Namen. 

Nummer des Knopfs, mit dem die Alertbox verlassen wurde (der am weitesten 
links stehende Knopf hat die Nummer 1). 
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FORMERROR (AES 53) 


Zeigt eine Warnmeldung für MS-DOS-Fehler an. Dies aus Kompatibilitätsgründen zum PC- 
GEM. Daher muß man zunächst die GEMDOS-Fehlemummem auf die Codierung von MS- 
DOS umrechnen! 


Deklaration in C: 

WORD form_error (WORD errnum) 
{ 

int_in[0] = errnum; 
return crys_if (53); 

} 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

— 

contrl[0] 

53 

Opcode für FORMJ3RROR 

contrl+2 

contrl[l] 

1 

# Einträge in int_in 

contrl+4 

contrl[2] 

1 

# Einträge in int_out 

contrl+6 

contrl[3] 

0 

# Einträge in addr_in 

contrl+8 

contrl[4] 

0 

# Einträge in addr_out 

intjn 

int_in[0] 

ermum 

int_out 

int_out(0] 

Retum-Wert 


Parameter: 

ermum: MS-DOS-Fehlemummer. Als Formel zur Berechnung der Fehlemummer aus 

dem vom GEMDOS gelieferten Code hat sich “(~ermo)~30” bewährt. 
2,3,18: “Diese Anwendung kann das angesprochene Objekt nicht finden.” 
4: “Die Anwendung benötigt mehr Platz zum Öffnen einer neuen 

Datei. Schließen Sie eine nicht benötigte Datei.” 

5: “Objekt mit gleichem Namen bereits vorhanden bzw. hat den “Nur- 

Lesen”-Status.” 

8,10,11: “Der Arbeitsspeicher reicht nicht für diese Anwendung.” 

15: “Floppy mit dieser Kennung unbekannt.” 
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form_error(): Nummer des Buttons, den der Benutzer gedrückt hat (immer 0, da alle Alert- 
Boxen nur einen Knopf haben) 

Bemerkungen 

Der Wortlaut der Fehlermeldungen in PC-GEM 2.0 weicht teilweise beträchtlich davon ab. 
Sinngemäß erhält man aber die gleichen Mitteilungen. 
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FORM_CENTER (AES 54) 


Zentriert Objekt in der Bildschirmmitte und gibt die tatsächliche Position auf dem Bildschirm 
zurück. Dabei werden für Breite und Höhe auch die speziellen Attribute wie z. B. “Outlined” 
berücksichtigt (Ausnahme: “Shadowed”). Diese Werte kann man dann speziell in Verbindung 
mit “form_dial()” und “objc_draw()” verwenden. 

In alten GEM-Versionen wird außerdem das Objekt so positioniert, daß der linke Rand auf 
einer Bytegrenze liegt. Wenn man also darauf erpicht ist, daß das Objekt an einer Byte-Grenze 
beginnt, sollte man dafür sorgen, daß die Objektbreite in Zeichen gerade ist (bei einem acht 
Pixel breiten Systemzeichensatz). 

Deklaration in C: 

WORD form_center (OBJECT *tree, WORD *pcx r WORD *pcy, WORD *pcw, 

WORD *pch) 

{ 

addr_in[0] = tree; 
crys_if (54 ); 

*pcx = int_out[lJ; 

*pcy = int__out [ 2 ]; 

*pcw = int_out[3]; 

*pch = int_out[4]; 
return int_out[0]; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

54 Opcode für FORM_CENTER 

contrl+2 

contrl[l] 

0 # Einträge in int_in 

contrl+4 

contrl [2] 

5 # Einträge in int_out 

contrl+6 

contrl[3] 

1 # Einträge in addrjn 

contrl+8 

contrl(4] 

0 # Einträge in addr_out 

addr_in 

addr_in[0] 

tree 

int_out | 

int_out[0] 

Remm-Wert (reserviert, immer 1) 

int_out+2 

int_out[l] 

pcx 




648 


ATARI Profibuch 


Adresse 

Feldelement 

Belegung 

int_out+4 

int_out[2] 

pcy 

int_out+6 

int_out[3] 

pcw 

int_out+8 

int_out[4] 

pch 


Parameter: 

tree: Anfangsadresse des Objektbaums 

pcx, pcy, 

pcw, pch: zentrierte Koordinaten 
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FORMJKEYBD (AES 55) 


Nimmt Tastatureingaben in ein Formular vor (siehe auch “objc_edit()”). Dabei wird unter 
Umständen das Eingabefeld geändert (Cursor-Tasten und “TAB”) oder das Default-Objekt 
selektiert (“RETURN”). 


Deklaration in C: 

WORD formjceybd (OBJECT *forra, WORD obj, WORD nxt_obj, 

WORD thechar, WORD *pnxt_obj, WORD *pchar) 

{ 

addr_in[0] = form; 
int_in[0] = obj; 
int_in[l] = thechar; 
int_in[2] - nxt__obj; 
crys_if (55) ; 

*pnxt_obj = int_out[lj; 

*pchar = int_out[2]; 
return intjout[0]; 

1 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

55 Opcode für FORM_KEYBD 

contrl+2 

contrl[l] 

3 # Einträge in int_in 

contrl+4 

contrl [2] 

3 # Einträge in int_out 

contrl+6 

contrl[3] 

1 # Einträge in addr_in 

contrl+8 

contrl[4) 

0 # Einträge in addr_out 

addr_in 

addr_in[0] 

form 

intjn 

int_in[0] 

obj 

int_in+2 

int_in[l] 

thechar 

int_in+4 

int_in[2] 

nxt__obj 

int_out 

int_out[0] 

Return-Wert 

int_out+2 

int_out[l] 

pnxt_obj 

int_out+4 

int„out[2] 

pchar 
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Parameter: 

form:- 

obj: 

nxt_obj: 

thechar: 

form_keybd(): 

pnxtobj: 

pchar: 


Anfangsadresse des Objektbaums 
Objektnummer des aktuellen EDIT-Objektes 
unbenutzt - auf 0 setzen 

Eingegebenes Zeichen, das eingetragen werden soll 
0: Exit-Objekt gedrückt 

>0: Dialog noch nicht beendet 

aktuelles EDIT-Objekt für den nächsten Aufruf (verändert sich, wenn 
“TAB”, Cursor-Tasten oder “RETURN” übergeben wurde) 

0: Zeichen war Cursortaste, “TAB” oder “RETURN” 

>0: übergebenes Zeichen 
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FORMJBUTTON (AES 56) 


Nimmt Mausknopfeingaben in ein Formular vor (simuliert das Anklicken eines Objekts). 


Deklaration in C: 

WORD form_button (OBJECT *form, WORD obj, WORD clks, 
WORD *pnxt_obj) 

{ 

addr_in[0] = form; 
int__in[0] = obj; 
int__in[l] = clks; 
crys_if (56) ; 

*pnxt_obj = int_out[1]; 
return int__out [0] ; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

56 Opcode für FORM. BUTTON 

contrl+2 

contrlfl] 

2 # Einträge in intjn 

contrl+4 

contrl [2] 

2 # Einträge in int_out 

contrl+6 

contrl[3] 

1 # Einträge in addrjn 

contrl+8 

contrl [4] 

0 # Einträge in addr_out 

addr_in 

addr_in[0] 

form 

int„in 

int_in[0] 

obj 

int_in+2 

intjn[l] 

clks 

int_out 

int_out[0] 

Return-Wert 

int_out+2 

int_out[l] 

pnxt_obj 


Parameter: 

form: Anfangsadresse des Objektbaumes 
obj: Objekt, das bearbeitet werden soll 
clk: Anzahl der zu simulierenden Mausklicks 
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form_button(): 

pnxt_obj: 


0: Es wurde zuletzt ein EXIT- oder TOUCHEXIT-Objekt angeklickt 

>0: Dialog noch nicht abgeschlossen 

neues aktuelles Objekt (bei Doppelklick auf ein TOUCHEXIT-Objekt wird 
Bit 15 gesetzt) oder 

0: Das nächste Objekt hat HIDDEN- oder DIS ABLED-Status oder ist 

nicht EDITABLE. 
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GRAF-Funktionen 


GRAFJRUBBOX (AES 70) 


Stellt auf dem Bildschirm eine “Gummiband-Box” dar. Dabei steht die linke obere Ecke fest, 
und die rechte untere Ecke folgt den Mausbewegungen des Benutzers, solange die Maustaste 
festgehalten wird. Daher sollte “graf_rubbox()” auch nur bei gedruckter Maustaste aufgerufen 
werden. 

Zurückgeliefert werden Breite und Höhe des Rechtecks in dem Moment, wenn die Maustaste 
losgelassen wird. 

Deklaration in C: 

WORD graf_rubbox (WORD xorigin, WORD yorigin, WORD wmin, WORD hmin, 
WORD *pwend, WORD *phend) 

1 

int_in[0] = xorigin; 
int_in[l] = yorigin; 
int_in[2] = wmin; 
int_in[3] = hmin; 
crys_if (70); 

*pwend = int_out[l]; 

*phend = int_out [ 2 ]; 
return int_out[0]; 

1 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

70 Opcode für GRAF.RUBBERBOX 

contrl+2 

contrl[l] 

4 # Einträge in int_in 

contrl+4 

contrl[2] 

3 # Einträge in int_out 

contrl+6 

contrl [3] 

0 # Einträge in addr_in 

contrl+8 

contrl [4] 

0 # Einträge in addr_out 

intjn 

int_in[0] 

xorigin 

int_in+2 

int_in[l] 

yorigin 

intJn+4 

int_in[2] 

wmin 
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Adresse 

Feldelement 

Belegung 

int_in+6 

int_in[3] 

hmin 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 

int_out+2 

int_out|l) 

pwend 

int_out+4 

int_out[2] 

phend 


Parameter: 

xorigin, 

yorigin: Koordinaten der linken oberen Ecke 

wmin, hmin: Kleinste (Anfangs-)Ausdehnung des Rechtecks 

pwend, phend: Ausdehnung des Rechtecks bei Beendigung der Funktion 

Bemerkungen 

In älteren GEM-Dokumentationen auch häufig als “graf_rubberbox()” bezeichnet! 
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GRAFDRAGBOX (AES 71) 


Läßt den Benutzer den Umriß eines Rechtecks (outline) innerhalb eines anderen Rechtecks 
verschieben. 


Deklaration in C: 

WORD grafjdragbox (WORD w, WORD h, WORD sx, WORD sy, WORD xc, 

WORD yc, WORD wc, WORD hc, WORD *pdx 7 WORD *pdy) 

{ 

int_in[0] = w; 
int_in[l] = h; 
int_in[2] = sx; 
int_in[3] = sy; 

±nt_in[4] = xc; 
int_in[5] = yc; 
int_in[6] = wc; 
int_in[7] = hc; 
crys_if (71); 

*pdx = int_out[l]; 

*pdy = int_out[2]; 
return int_out[0]; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

71 Opcode für GRAF_DRAGBOX 

contrl+2 

contrl[l] 

8 # Einträge in intjn 

contrl+4 

contrl [2] 

3 # Einträge in int_out 

contrl+6 

contrl[3] 

0 # Einträge in addr_in 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

int_in 

int„in[0] 

w 

int_in+2 

int_in[l] 

h 

int_in+4 

int_in[2] 

sx 

int_in+6 

int„in[3] 

sy 

int_in+8 

int_in[4] 

xc 

int_in+10 

int_in[5] 

yc 
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Adresse 

Feldelement 

Belegung 

int_in+12 

int_in[6] 

wc 

int_in+14 

int_in[7] 

hc 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 

int_out+2 

int_out[l] 

pdx 

int_out+4 

int_out[2] 

pdy 


Parameter: 

w, h: Maße des zu bewegenden Rechtecks 

sx, sy: Anfangskoordinaten des Rechtecks 

xc, yc, wc, hc: Maße des “äußeren” Rechtecks 

pdx, pdy: Koordinaten des verschobenen Rechtecks bei Loslassen der Maustaste 
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GRAF_MBOX (AES 72) 


Zeichnet eine sich bewegende Box mit konstanter Größe. In älteren GEM-Dokumentationen 
wird diese Funktion auch häufig als “graf_movebox()” bezeichnet! 

Deklaration in C: 

WORD grafjnbox (WORD w, WORD h, WORD srcx, WORD srcy, WORD dstx, 

WORD dsty) 

{ 

int_in[0] = w; 
int_in[l] = h; 
int_in[2] = srcx; 
int_in[3] = srcy; 
int_in[4] = dstx; 
int_in[5] = dsty; 
return crys_if (72); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

72 Opcode für GRAF_MBOX 

contrl+2 

contrl [1] 

6 # Einträge in intjn 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

0 # Einträge in addrjn 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

intjn 

int_in[0] 

w 

int_in+2 

int„in[l] 

h 

int_in+4 

int_in[2] 

srcx 

int_in+6 

int_in[3] 

srcy 

int_in+8 

int_in[4] 

dstx 

int_in+10 

int_in[5] 

dsty 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 


Parameter; 

w, h; Maße des Rechtecks 

stx, sty: Anfangsposition 

dstx, dsty: Endposition 
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GRAFGROWBOX (AES 73) 


Zeichnet ein sich bewegendes Rechteck, das sich ausdehnt. 


Deklaration in C: 

WORD graf_growbox (WORD stx, WORD sty, WORD stw, WORD sth, 

WORD finx, WORD finy, WORD finw, WORD finh) 

{ 

int_in[0] = stx; 
int_in[l] = sty; 
int_in(2] = stw; 
int_in[3] = sth; 
int_in[4] = finx; 
int__in[5] = finy; 
int__in[6] = finw; 
int_in[7] = finh; 
return crys_if (73); 

) 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

73 Opcode für GRAF GROWBOX 

contrl+2 

contrlfl] 

8 # Einträge in int_in 

contrl+4 

contrl [2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

0 # Einträge in addr_in 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

int_in 

int__in[0J 

stx 

int.in+2 

int_in[l] 

sty 

int_in+4 

int_in[2] 

stw 

int_in+6 

int_in[3] 

sth 

int_in+8 

int_in[4] 

finx 

int_in+10 

int_in[5] 

finy 

int_in+12 

int_in[6] 

finw 

int_in+14 

int_in[7] 

finh 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 
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Parameter: 

stx, sty, stw, sth: Anfangsmaße des Rechtecks 

finx, finy, Finw, fxnh: Endmaße des Rechtecks 

Bemerkungen 

Ab PC-GEM 2.0 wird der Befehl ignoriert. 
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GRAF_SHRINKBOX (AES 74) 


Zeichnet ein sich bewegendes Rechteck, das schrumpft. 


Deklaration in C: 

WORD graf__shrinkbox (WORD finx, WORD finy, WORD finw, WORD finh, 

WORD stx, WORD sty, WORD stw, WORD sth) 

{ 

int_in[0] = finx; 
int_infl] = finy; 
int_in[2] = finw; 
int_in[3] = finh; 
int__in[4] = stx; 
int__in[5] = sty; 
int_in[6] = stw; 
int_in[7] = sth; 
return crys_if (74); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

74 Opcode für GRAF_SHRINKBOX 

contrl+2 

contrl[l] 

8 # Einträge in int_in 

contrl+4 

contrl[2] 

I # Einträge in int_out 

contrl+6 

contrl[3] 

0 # Einträge in addr_in 

contrl+8 

contrl [4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

finx 

int_in+2 

int_in[l] 

finy 

int_in+4 

int_in[2] 

finw 

int_in+6 

int_inf3] 

finh 

int_in+8 

int_in[4] 

stx 

int_in+10 

int_in[5] 

sty 

int_in+12 

int_in[6] 

stw 

int_in+14 

int_in[7] 

sth 

int_out 

int_out[0] 

Retum-Wert (0: Fehler) 
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Parameter: 

finx, finy, finw, finh: Endmaße des Rechtecks 
stx, sty, stw, sth: Anfangsmaße des Rechtecks 

Bemerkungen 

Wird ab PC-GEM 2.0 ignoriert. 
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GRAF_WATCHBOX (AES 75) 


Der Objektstatus eines Objekts wird in Abhängigkeit von der Position des Mauszeigers gesetzt 
(je nachdem, ob er sich innerhalb oder außerhalb des Objekts befindet). Die Funktion bricht 
bei Loslassen des Mausknopfes ab. 


Deklaration in C: 

WORD graf_watchbox (OBJECT *tree, WORD obj, WORD instate, 
WORD outstate) 

{ 

addr_in[0] = tree; 
int_in[l] = obj; 
int_in[2] = instate; 
int_in[3] = outstate; 
return crys_if (75); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

75 Opcode für GRAF_WATCHBOX 

contrl+2 

contrl[l] 

4 # Einträge in int.jn 

contrl+4 

contrl [2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

I # Einträge in addrjn 

contrl+8 

contrl [4] 

0 # Einträge in addr_out 

intjn 

int_in[0] 

reserviert 

intJn+2 

int_in[lj 

obj 

int_in+4 

int_in[2] 

instate 

int_jn+6 

int__in[3] 

outstate 

addrjn 

addr_in[0] 

tree 

int_out 

int_out[0] 

Retum-Wert 


Parameter: 

obj: Objektnummer des betreffenden Objekts 
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instate: 


outstate: 


tree: 

graf_watchbox(): 


Status des Objekts, wenn sich der Mauszeiger innerhalb derBegrenzung 
befindet. Bitbelegung: 

NORMAL (0x0000) 

SELECTED (0x0001) 

CROSSED (0x0002) 

CHECKED (0x0004) 

DISABLED (0x0008) 

OUTLINED (0x0010) 

SHADOWED (0x0020) 

Status des Objekts, wenn sich der Mauszeiger außerhalb der Begrenzung 
befindet 

Anfangsadresse des Objektbaums 
Beim Loslassen des Knopfes war der Mauszeiger 
0: außerhalb des Objekts 

1: innerhalb des Objekts. 
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GRAFSLIDEBOX (AES 76) 


Dient zur Abfrage von “Schiebereglern”. Dazu verwendet man ein Rechteck, das Child eines 
anderen Rechtecks in einem Objektbaum ist. 

Den Umriß (outline) dieses Objekts kann man dann entweder horizontal oder vertikal 
innerhalb der Grenzen des übergeordneten Rechtecks bewegen. 

Aufruf nur bei gedrückter Maustaste, da beim Loslassen des Knopfes abgebrochen wird. 


Deklaration in C: 

WORD graf_slidebox (OBJECT *tree, WORD parent, WORD obj, 
WORD isvert) 

{ 

addr_in[0] = tree; 
int_in[0] = parent; 
int_in[l] = obj; 
int__in[2] = isvert; 
return crys_if (76); 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

76 Opcode für GRAF_SLIDEBOX 

contrl+2 

contrl[l] 

3 # Einträge in int_in 

contrl+4 

contrl[2J 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

1 # Einträge in addrjn 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

parent 

int__in+2 

int_in[l] 

obj 

int_in+4 

int_in[2] 

isvert 

addrjn 

addr_in[0] 

tree 

int.out 

int_out[0] 

Return-Wert 
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Parameter: 


parent: 

obj: 

vh: 

tree: 

graf_slidebox(): 


Objektnummer des übergeordneten Rechtecks 
Objektnummer des zu verschiebenden Rechtecks (der Schieber) 

0: horizontal verschieben 
1: vertikal verschieben 
Anfangsadresse des Objektbaums 

relative Position des Schiebers innerhalb des übergeordneten Objekts 
(0: ganz links bzw. oben, 1000: ganz rechts bzw. unten) 
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GRAF HANDLE (AES 77) 


Liefert das Handle der Bildschirm-Workstation, auf die die AES ausgeben. Weiterhin erhält 
man die Ausmaße in Pixeln eines Zeichens im Systemzeichensatz. 

Deklaration in C: 

WORD graf_handle (WORD *pwchar, WORD *phchar, WORD *pwbox, 

WORD *phbox) 

{ 

crys_if (77); 

*pwchar = int_out[1]; 

*phchar = int_out [2] ; 

*pwbox = int_out[3]; 

*phbox = int_out[4]; 
return int_out[0]; 
i 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

77 Opcode für GRAF_HANDLE 

contrl+2 

contrl[l] 

0 # Einträge in int_in 

contrl+4 

contrl[2] 

5 #Einträge in int_out 

contrl+6 

contrl[3] 

0 # Einträge in addrjn 

contrl+8 

contrl[4] 

■ 0 # Einträge in addr_out 

int_out 

int_out[0] 

handle 

int_out+2 

int_out[l] 

pwchar 

int_out+4 

int_out[2] 

phchar 

int_out+6 

int_out[3] 

pwbox 

int_out+8 

int_out[4] 

phbox 


Parameter: 

graf_handle(): Handle der von den AES geöffneten VDI-Workstation 

pwchar, phchar; Breite und Höhe (in Punkten) eines Zeichens aus dem Systemzeichen¬ 
satz (für Menüs und Dialoge). 

pwbox, phbox: Maße eines Quadrates, in das ein beliebiges Zeichen aus dem System¬ 

zeichensatz komplett hineinpassen würde. Diese Information wird auch 
von den AES für die Breiten der einzelnen Fenster-Elemente verwendet! 
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GRAF_MOUSE (AES 78) 


Wählt für den Mauszeiger entweder eine von acht vordefinierten oder eine vom Benutzer 
definierte Form. Alles was nicht Pfeil oder “BUSYBEE” ist, sollte man nur innerhalb des 
Arbeitsbereichs des eigenen (obersten) Fensters verwenden! 

Deklaration in C: 

WORD grafjnouse (WORD m_number, MFORM *m_addr) 

{ 

int_in[0] = ra_number; 
addr_in[0] = m_addr; 
return crys_if (78); 

) 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

78 Opcode für GRAF_MOUSE 

contrl+2 

contrl[l] 

1 # Einträge in int_in 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrl [3J 

1 # Einträge in addr jn 

contrl+8 

contrl [4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

m_number 

addr_in 

addr_in[0] 

m_addr 

int_out 

int_out[0] 

Retum-Wert (0: Fehler) 


Parameter: 


m_number: 


Nummer der Mausform: 


ARROW (0): 
TEXTCRSR (1): 
HOURGLASS (2): 
BUSYBEE (2): 


Pfeil 

Text-Cursor (vertikaler Strich): Texteingabe 
oder 

Biene (Bezeichnung stammt vom PC-GEM, bei dem 
statt dessen eine Sanduhr gezeigt wird): Computer ist 
beschäftigt (und fleißig). 
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POINT_HAND(3): zeigende Hand: Auswahl, Dimensionierung 
FLATJHAND (4): flache Hand mit ausgestreckten Fingern: Auswahl/ 
Positionierung 

THIN_CROSS (5): feines Fadenkreuz: Auswahl/Zeichnen 
THICK_CROSS (6): breites Fadenkreuz 
OUTL_CROSS (7): Umrissenes Fadenkreuz 
USER_DEF (255): in faddr adressierte Mausform 
M_OFF (256): Mauszeiger ausschalten (Aufrufe können verschachtelt 

werden!) 

M_ON (257): Mauszeiger einschalten 

m_addr: Zeiger auf Mausform folgender Gestalt: 

typedef struct 

{ 

WORD mf_xhot; 

WORD mf_yhot; 

WORD mf_nplanes; 

WORD mf_fg; 

WORD mf_bg; 

WORD mf_mask[16]; 

WORD mf_dat a[16]; 

} MFORM; 


/* X-Pos. Aktionspunkt */ 

/* Y-Pos. Aktionspunkt */ 

/* Anzahl planes (=1) */ 

/* Maskenfarbe (normal: 0) */ 
/* Zeigerfarbe (normal: 1) */ 
/* Maskenform */ 

/* Zeigerform */ 
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GRAFJMKSTATE (AES 79) 



Liefert Mausposition sowie Status der Maustasten und der Tastatur. 

Deklaration in C: 

WORD grafjnkstate (WORD *pmx, WORD *pmy, WORD *pinstate, 
WORD *pkstate) 

{ 

crys__if (79); 

*pmx = int_out[l]; 

*pmy = int_out[2]; 

*pmstate = int_out [3]; 

*pkstate = int_out[4] ; 
return int_out[0]; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

79 Opcode für GRAF_MKSTATE 

contrl+2 

contrlfl] 

0 # Einträge in int_in 

contrl+4 

contrl[2] 

5 # Einträge in int_out 

contrl+6 

contrl [3] 

0 # Einträge in addr_in 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

int_out 

int_.out[0] 

Retum-Wert (reserviert, immer 1) 

int_out+2 

int_out[l] 

pmx 

int_out+4 

int_out[2] 

pmy 

int_out+6 

int_out[3] 

pmstate 

int_out+8 

int_out[4] 

pkstate 


Parameter: 

pmx, pmy: aktuelle Mausposition 

pmstate: Status der Maustasten (Bit 0: linke Taste usw.) 

pkstate: Tastaturstatus. Bitbelegung: 

K^RSHIFT (0x0001): rechte Shift-Taste 

K_LSHIFT (0x0002): linke Shift-Taste 

K_CTRL (0x0004): Control-Taste 

K_ALT (0x0008): Altemate-Taste 
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SCRP-Fimktionen 


SCRP_READ (AES 80) 


Liest den Pfadnamen für das Directory (scrap directoiy), in dem Daten für die Zwischenablage 
(clipboard) abgespeichert werden. 

Deklaration in C: 

WORD scrp_read (CHAR *pscrap) 

{ 

addr_in[0] = pscrap; 
return crys_if (80); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

80 

Opcode für SCRP_READ 

contrl+2 

contrl[l] 

0 

# Einträge in int_in 

contrl+4 

contrl[2] 

1 

# Einträge in int_out 

contrl+6 

contrl[3] 

1 

# Einträge in addr_in 

contrl+8 

contrl[4] 

0 

# Einträge in addr_out 

addr_in 

addr_in[0] 

pscrap 


int_out 

int_out[0] 

1 Retum-Wert 


Parameter: 

pscrap: Puffer für den Pfadnamen 

(Vorsicht! Möglicherweise große Länge bei tief verschachtelten Ordnern!). 
scrp_read(): Atari-GEM: 0: Fehler 

PC-GEM 2.0: -1: Kein Pfad vorhanden 

>=0: Bitvektor, der darüber Auskunft gibt, ob Dateien mit 
gewissen Extensions gefunden worden sind. Bitbelegung: 
BitO: SCRAP.CSV 
Bit 1: SCRAP.TXT 
Bit 2: SCRAP.GEM 
Bit 3: SCRAP.IMG 
Bit 4: SCRAP.DCA 
Bit 5: SCRAP.USR 
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SCRP_WRITE (AES 81) 


Legt den Zugriffspfad für das aktuelle Scrap-Directory fest. 


Deklaration in C: 

WORD scrp_write {CHAR *pscrap) 
{ 

addr_in[0] = pserap; 
return crys_if (81); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

81 

Opcode für SCRPJWRITE 

contrl+2 

contrl[l] 

0 

# Einträge in int_in 

contrl+4 

contrl[2] 

1 

# Einträge in int_out 

contrl+6 

contrl[3] 

1 

# Einträge in addr_in 

contrl+8 

contrl [41 

0 

# Einträge in addr_out 

addr_in 

addr_in[0] 

pserap 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 


Parameter: 

pserap: Name des neuen Pfades 
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SCRP CLEAR (AES 82) - nur in PC-GEM ab Version 2.0 


Löscht alle Dateien im aktuellen Scrap-Directory. 

Deklaration in C: 

WORD scrp_clear (void) 

{ 

return crys__if (82) ; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

82 

Opcode für SCRP_CLEAR 

contrl+2 

contrl [1] 

0 

# Einträge in int_in 

contrl+4 

contrl [2] 

1 

# Einträge in int_out 

contrl+6 

contrl[3] 

0 

# Einträge in addr_in 

contrl+8 

contrl[4] 

0 

# Einträge in addr_out 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 
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FSEL-Funktionen 


FSELINPUT (AES..90) 


Bringt die handelsübliche Dateiauswahlbox (den File-Selector) auf den Bildschirm. 

Alte AES-Versionen (vor GEM 1.4) können maximal 100 Dateien anzeigen und warnen 
gegebenenfalls mit einem “Ping”, wenn Dateien deshalb nicht gezeigt werden können. 
Daneben gab es auch noch schwerwiegendere Fehler, namentlich bei der Behandlung von 
BIOS-Fehlem (zum Beispiel: Diskette nicht eingelegt). 

Ab GEM 1.4 hat Atari den File-Selector überarbeitet und viele (aber leider nicht alle) Fehler 
beseitigt. Wichtigste Neuerungen sind die Buttons, mit denen man per Mausklick auf andere 
Laufwerke wechseln kann und die konfigurierbare Titelzeile (siehe “fsel_exinput()”). 

Auf dem PC ging die Entwicklung in eine andere Richtung. Zunächst kann man zwischen 
verschiedenen logischen Laufwerken umschalten, indem man nach Erreichen des Wurzelver¬ 
zeichnisses nochmals die Close-Box anklickt (man erhält dann eine Liste der vorhandenen 
Laufwerke - siehe dazu auch “appl_bvset()”). Außerdem kann zusätzlich am Ende des Pfad¬ 
namens eine Liste von - durch Kommata getrennten - Suchmasken angegeben werden. 

Deklaration in C: 

WORD fsel_input (CHAR *pipath, CHAR *pisel, WORD *pbutton) 

{ 

addr_in[0] = pipath; 
addr_in[l] = pisel; 
crys_if (90); 

*pbutton = int_out[1]; 
return int_out[0]; 

} 

GEM-Arrays; 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

90 

Opcode für FSELJNPUT 

contrl+2 

contrl[l] 

0 

# Einträge in intjn 

contrI+4 

contrl[2] 

2 

# Einträge in int_out 

contrl+6 

contrl(3] 

2 

# Einträge in addr Jn 
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Adresse 

Feldelemente 

Belegung 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

addr_in 

addr jn[0] 

pipath 

addr_in+4 

addr_in[l] 

pisel 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 

int_out+2 

int_out[l] 

pbutton 


Parameter: 


pipath: 


pisel: 

pbutton: 

fsel_input(): 


Name des standardmäßigen absoluten Zugriffspfades inkl. angehängter Such¬ 
maske. Enthält nach dem Aufruf den vom Benutzer geänderten Pfadnamen 
(also genau den, der auf dem Bildschirm zu sehen ist). 

Vorgewählter Dateiname. Enthält nach dem Aufruf den vom Benutzer ausge¬ 
wählten Dateinamen. 

0: Es wurde “Abbruch” gedrückt. 

1: Es wurde “OK” gedrückt. 

Sollte man auf keinen Fall ignorieren, weil beispielsweise bei Speichermangel 
ein Fehler gemeldet wird! 
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FSEL EXINPUT (AES 91) - erst ab GEM 1.4 


Entspricht “fsel_input()” mit dem Unterschied, daß zusätzlich eine Zeichenkette als Dialogbox- 
Titel übergeben werden kann. 


Deklaration in C: 

WORD fsel_exinput (CHAR *pipath, CHAR *pisel, WORD *pbutton, 
CHAR *plabel) 

{ 

addr_in[0] = pipath; 
addr_in[l] = pisel; 
addr_in[2] = plabel; 
crys_if (91); 

*pbutton = int_out[l]; 
return int_out[ 0 ]; 

1 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

91 Opcode für FSELJEXINPUT 

contrl+2 

contrl[l] 

0 # Einträge in int Jn 

contrl+4 

contrl [2] 

2 # Einträge in int„out 

contrl+6 

contrl[3] 

3 # Einträge in addrjn 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

addrjn 

addr_in[0] 

pipath 

addr_in+4 

addr_in[l] 

pisel 

addrJn+8 

addr_in[2] 

plabel 

int_out 

int_out.[0] 

Return-Wert (0: Fehler) 

int_out+2 

int„out[l] 

pbutton 


Parameter: 

pipath: Name des standardmäßigen absoluten Zugriffspfades inkl, angehängter Such¬ 

maske. Enthält nach dem Aufruf den vom Benutzer geänderten Pfadnamen 
(also genau den, der auf dem Bildschirm zu sehen ist). 
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pisel: 

plabel: 

pbutton: 

fsel_exinput(): 


Bemerkungen 

Und so sollte man das Vorhandensein von “fsel_exinput 0” testen (die AES-Versionen 2.x 
werden aus Rücksicht auf “ABC-GEM” herausgefiltert): 

if (((global[0] >=0x0140) && (global[0] <0x0200)) || 

(global[0] >= 0x0300)) 

{ 


Vorgewählter Dateiname. Enthält nach dem Aufruf den vom Benutzer 
ausgewählten Dateinamen. 

Titelzeile 

0: Es wurde “Abbruch” gedrückt. 

1: Es wurde “OK” gedrückt. 

Sollte man aufkeinenFall ignorieren, weil beispielsweise bei Speichermangel 
ein Fehler gemeldet wird! 


/* fsel_exinput verfügbar */ 

} 

eise 

{ 

/* statt dessen fsel_input benutzen */ 
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WIND-Funktionen 


WINDCREATE (AES 100) 


Meldet bei den AES ein neues Fenster an, für das eine entsprechende Fenster-Nummer 
(window handle) zurückgeliefert wird. 

Gleichzeitig werden Fenster-Attribute und maximale Größe festgelegt. 


Deklaration in C: 

WORD wind__create (WORD kind, WORD wx, WORD wy, WORD ww, WORD wh) 
{ 

int__in[0] = kind; 
int_in[l] = wx; 
int_in[2] = wy; 
int_in[3] = ww; 
int_in[4] = wh; 
return crys_if (100) ; 

} 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

100 Opcode für WIND_CREATE 

contrl+2 

contrl[l] 

5 # Einträge in intjn 

contrl+4 

contrl [2] 

1 # Einträge in mt_out 

contrl+6 

contrl [3] 

0 # Einträge in addrjin 

contrl+8 

contrl[4] 

0 # Einträge in addr„out 

int_in 

int_in[0] 

kind 

int_in+2 

int_in[l] 

wx 

int_in+4 

int_in[2] 

wy 

intJn+6 

int_in[3] 

ww 

int_in-t-8 

int_in[4] 

wh 

int_out 

int_out[0] 

Retum-Wert (<0: Fehler) 
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Parameter: 

kind: Vorhandene Fensterkomponenten. Bitbelegung: 

NAME (0x0001): Titelbalken mit Name 

CLOSE (0x0002): Schließbox 

FULL (0x0004): Full-Box 

MO VE (0x0008): Bewegungsbox 

(Schattierung im Balken) 

INFO (0x0010): Infozeile 

SIZE (0x0020): Größenverstellung 

UP ARROW (0x0040): Pfeil nach oben 

DNARROW (0x0080): Pfeil nach unten 

VSLIDE (0x0100): Vertikaler Schieber 

LFARROW (0x0200): Pfeil nach links 

RTARROW (0x0400): Pfeil nach rechts 

HSLIDE (0x0800): Horizontaler Schieber 

HOTCLOSEBOX (0x1000): Close-Box hat Auto-Repeat 

(erst ab PC-GEM 2.0) 

wx, wy, ww, wh: Fensterkoordinaten bei größter Ausdehnung 

wind_create(): Fenster-Kennung (window handle) des erzeugten Fensters (<0: Fehler) 
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WINDOPEN (AES101) 


Ein vorher mit “wind_create()” erzeugtes Fenster wird auf dem Bildschirm dargestellt. 
Titelzeile, Infozeile und Slider müssen vorher mit “wind_set()” gesetzt werden! 

Deklaration in C: 

WORD wind_open (WORD handle, WORD wx, WORD wy, WORD ww, WORD wh) 

! 

int_in(0] = handle; 
int_in[l] = wx; 
int_in[2] = wy; 
int_in[3] = ww; 

±nt_in[4] = wh; 
return crys_if (101); 

) 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

101 Opcode für WIND_OPEN 

contrl+2 

contrl[l] 

5 # Einträge in intjn 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

0 # Einträge in addr Jn 

contr]+8 

contrl [4] 

0 # Einträge in addr_out 

intjn 

intjn[0] 

handle 

int_in+2 

int_in[l] 

wx 

int_in+4 

intjn [2] 

wy 

int_in+6 

intjn[3] 

ww 

int_in+8 

intjn[4] 

wh 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 


Parameter: 

handle: Kennung (handle) des zu öffnenden Fensters 

wx, wy, ww, wh: Anfangsmaße des Fensters 

Bemerkungen 

Das Öffnen des Fensters führt automatisch dazu, daß der Screen Manager eine “Redraw”- 
Mitteilung über die Fläche des Arbeitsbereichs verschickt. 
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WIND_CLOSE (AES102) 


Ist das Gegenstück zu “wind_open()” und schließt das betreffende Fenster. Endgültig gelöscht 
wird es mit “wind_delete()”. 

Deklaration in C: 

WORD wind_close (WORD handle) 

{ 

int_in[0] = handle; 
return crys_if (102); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrlfO] 

102 

Opcode für WINDJXOSE 

contrl+2 

contrl)! j 

1 

# Einträge in int_in 

contrl+4 

contrl[2] 

1 

# Einträge in int__out 

contrl+6 

contrl[3] 

0 

# Einträge in addr_in 

contrl+8 

contrl[4] 

0 

# Einträge in addr_out 

int_in 

int_in[0] 

handle 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 


Parameter; 

handle: Kennung des zu schließenden Fensters 
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WHND_DELETE (AES103) 


Löscht ein Fenster komplett und gibt dabei den dafür intern benötigten Speicherplatz und die 
Kennung (handle) wieder frei. 

Deklaration in C: 

WORD wind_delete (WORD handle) 

{ 

int_in[0] = handle; 
return crys_if (103); 

> 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

103 

Opcode für WIND JDELETE 

contrl+2 

contrl[l] 

1 

# Einträge in int_in 

contrl+4 

contrl [2] 

1 

# Einträge in int_out 

contrl+6 

contrl[3] 

0 

# Einträge in addr_in 

contrl+8 

contrl [4] 

0 

# Einträge in addr_out 

intjn 

int_in[0] 

handle 

int_out 

int_out[0] 

Retum-Wert (0: Fehler) 


Parameter: 

handle: Kennung des zu löschenden Fensters 
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WINDGET (AES104) 


Liefert je nach Funktionsnummer verschiedene Informationen über ein Fenster. 

Deklaration in C: 

WORD wind_get (WORD w_handle, WORD w_field, WORD *pwl, WORD *pw2, 
WORD *pw3, WORD *pw4) 

{ 

int_jln[0] = w_handle; 
int_in[l] = w__field; 
crys_if (104) ; 

*pwl = int_out [ 1]; 

*pw2 = int_out[2]; 

*pw3 = int__out [3]; 

*pw4 = int_out[4]; 
return int_out[0]; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl fOj 

104 Opcode für WIND_GET 

contrl+2 

contrlfl] 

2 # Einträge in int_in 

contrl+4 

contrl [2] 

5 # Einträge in int_out 

contrl+6 

contrl[3] 

0 # Einträge in addrjn 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

w_handle 

int_in+2 

int_in[l] 

w_field 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 

int_out+2 

int_out[l] 

pwl 

int_out+4 

int_out[2] 

pw2 

int_out+6 

int_out[3] 

pw3 

int_out+8 

int_outf4] 

pw4 


Parameter: 

wjiandle: Kennung des betreffenden Fensters 

w_field: Gewünschte Information. Die Inhalte von pwl... pw4 hängen ab von: 
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WF_WORKXYWH (4): 

WF_CURRXYWH (5): 

WF_PREVXYWH (6): 

WF_FULLXYWH (7): 

WFJHSLIDE (8): 
WF_VSLEDE (9): 
WF_TOP (10): 
WFJFIRSTXYWH(ll): 

WF_NEXTXYWH (12): 


Berechnet Koordinaten des Arbeitsbereichs des Fensters. 

pwl: X-Position 

pw2: Y-Position 

pw3: Breite 

pw4: Höhe 

Berechnet Koordinaten des gesamten Fensters einschließlich 

Ränder etc. 

pwl: X-Position 

pw2: Y-Position 

pw3: Breite 

pw4: Höhe 

Berechnet Gesamtgröße des vorherigen Fensters. 

pwl: X-Position 

pw2: Y-Position 

pw3: Breite 

pw4: Höhe 

Berechnet die Gesamtgröße des Fensters in seiner größtmögli¬ 
chen Ausdehnung, 
pwl: X-Position 

pw2: Y-Position 

pw3: Breite 

pw4: Höhe 

Liefert Position des horizontalen Schiebers, 
pwl: (0: ganz links, 1000: ganz rechts) 

Liefert Position des vertikalen Schiebers, 
pwl: (0: ganz oben, 1000: ganz unten) 

Liefert Kennung des obersten Fensters, 
pwl: handle 

Liefert Koordinaten des ersten Rechtecks in der Rechteckliste 

des Fensters. 

pwl: X-Position 

pw2: Y-Position 

pw3; Breite 

pw4: Höhe 

Liefert die Koordinaten des nächsten Rechtecks in der Recht- 

eckliste des Fensters. 

pwl: X-Position 

pw2: Y-Position 

pw3: Breite 

pw4: Höhe 
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WF_HSLSIZE (15): Die Größe des horizontalen Schiebers relativ zum Balken wird 

berechnet. 

pwl: -1: Minimalgröße 

1-1000: klein-gesamte Breite 

WF_VSLSIZE (16): Die Größe des vertikalen Schiebers relativ zum Balken wird 

berechnet. 

pwl: -1: Minimalgröße 

1-1000: . klein-gesamte Höhe 

WF_SCREEN (17): Adresse und Länge des “Quarter Screen Buffers” für Drop- 

Down-Menüs und Alarmboxen wird berechnet. Bei TOS 1.02 
wird für die Länge 0 zuriickgeliefert (obwohl der Puffer 8000 
Bytes faßt). 

pw 1: High-Word der Adresse 

pw2: Low-Word der Adresse 

pw3: High-Word der Länge 

pw4: Low-Word der Länge 

Bemerkungen 

Einmal mehr hat Digital Research hier die eingeführten Bezeichnungen geändert (nunmehr 
“WF_WXYWH (4)”, “WF_CXYWH (5)”, “WF_PXYWH (6)” und “WF_FYXWH (7)”). 

Eine Beispielfunktion für “WF_SCREEN”: 

void getQSB (void **where, LONG *length) 

{ 

WORD wl, w2, w3, w4; 

/* Hinweis: bei älteren TC-Versionen ist das Binding für 
windjget (..., WF_SCRE£N, ...) nicht korrekt und liefert 
falsche Resultate! */ 

wind__get (0, WF_SCREEN, &wl, &w2, &w3, &w4); 

*where = (void *)((OWORD) wl * 65536L + (DWORD) w2); 

*length = (DWORD) w3 * 65536L + (DWORD) w4; 

/* Sonderfall: TOS 1.02 */ 

if ((*length == 0L) && (global[0] == 0x0120)) 

*length = 8000L; 

} 
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Und der Aufruf im Programm: 

void *where; 

LONG length; 

getQSB (&where, &length); 

printf ("Adresse: %p, Länge: %ld Bytes\n", where, length); 
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WINDSET (AES 105) 


Je nach Funktionsnummer werden verschiedene Fenstereigenschaften verändert. 

Deklaration in C: 

WORD wind_set (WORD w_handle, WORD w_field, WORD wl, WORD w2, 
WORD w3, WORD w4) 

{ 

int__in[0] = w_handle; 
int_in[l] = w_field; 
int_in[2] = wl; 
int_in[3] = w2; 
int_in[4] = w3; 
int_in[5] = w4; 
return crys_if (105); 

} 

GEM-Arrays: 


Adresse ' 

Feldelement 

Belegung 

contrl 

contrl [0] 

105 Opcode für WIND_SET 

contrl+2 

contrl[l] 

6 # Einträge in int_in 

contrl+4 

contrl [2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

0 # Einträge in addr_in 

contrl+8 

contrl [4] 

0 # Einträge in addr_out 

int_in 

int„in[0] 

handle 

int_in+2 

int_in[l] 

field 

int_in+4 

int_in[2] 

wl 

int_in+6 

int_in[3] 

w2 

int_in+8 

int_in[4] 

w3 

int_in+10 

int„in[5] 

w4 

int_out 

int_out[0) 

Retum-Wert (0: Fehler) 


Parameter: 

wjiandle: Kennung des Fensters 

w_field: Funktionsnummer. wl...w4 werden in Abhängigkeit davon interpretiert: 
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WF NAME (2): 
WFJNFO (3): 
WF_CURRXYWH (5): 


WF_HSLIDE (8): 

WF_VSLIDE (9): 

WF_TOP (10): 
WFJNEWDESK (14): 


WF_HSLSIZE (15): 
WF_VSLSIZE (16): 


Legt neuen Fenstemamen fest. 

wl und w2: Zeiger auf Zeichenkette (GEM benutzt nur den 
Zeiger, legt also keine Kopie an). 

Legt neue Info-Zeile fest. 

wl und w2: Zeiger auf Zeichenkette (GEM benutzt nur den 
Zeiger, legt also keine Kopie an). 

Setzt Fenstergröße fest, 
wl: X-Position 
w2: Y-Position 
w3: Breite 
w4: flöhe 

Setzt neue Position für den horizontalen Schieber 
wl: (0: ganz links, 1000: ganz rechts) 

Setzt neue Position für den vertikalen Schieber 
wl: (0: ganz oben, 1000: ganz unten) 

Fenster wird zum aktuellen (obersten) Fenster 

Setzt neuen Default-Objektbaum; funktioniert nur mit Fenster 0 

(Hintergrundfenster). Ein Nullzeiger erlaubt es, wieder den 

Standardhintergrund zu setzen (kann nach der Ausführung von 

GEM-Programmen aus eigenen Programmen heraus wichtig 

sein). 

wl: Adresse des Objektbaums (High) 

w2: Adresse des Öbjektbaums (Low) 

w3: Objektnummer des ersten darzustellenden Objekts 

Setzt relative Größe des horizontalen Schiebers 

wl: -1 (Minimalgröße) 

1-1000 (klein-volle Breite) 

Setzt relative Größe des vertikalen Schiebers 
wl: -1 (Minimalgröße) 

1-1000 (klein-volle Höhe) 


in PC-GEM 2.0 neu hinzugekommen: 

WF_TATTRB (18): Setzt den “Fenster-Attributvektor” (von Digital Research nicht 

weiter dokumentiert), 
w 1: 0: Fenster ist oberstes Fenster 

1: Fenster ist nicht oberstes Fenster 

WF_SIZTOP (19): Macht das angegebene Fenster zum aktiven, ohne die Reihenfol¬ 

ge der darunterliegenden zu ändern. Gleichzeitig können neue 
Position und Größe angegeben werden: 
wl: X-Position 
w2: Y-Position 
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w3: Breite 
w4: Höhe 

hingegen in Atari-GEM ab Version 3.0: 

WF_COLOR (18): Farben der verschiedenen Fensterelemente festlegen: 

wl: Fensterelement: 

W_BOX (0): Fensterhintergrund (G_IBOX) 

W_TITLE (1): Titelbox, enthält Namen, Volle-Größe-Box und Schließ¬ 

box (G_BOX) 

W_CLOSER (2): Schließbox (G_BOXCHAR) 

W_NAME (3): Namenszeile (G_BOXTEXT) 

W„FULLER (4): Volle-Größe-Box (G_BOXCHAE) 

W_INFO (5): InfozeUe (G_BOXTEXT) 

W DATA (6): Objekt, das die restlichen Fensterelemente enthält 

(GJBOX) 

W_WORK (7): Arbeitsbereich des Fensters, freie Fläche (GJOBOX) 

W_SIZER (8): Größenveränderungsbox (GJBOXCHAR) 

W_VBAR (9): enthält die Elemente des vertikalen Balkens (G_BOX) 

WJUP ARROW (10): Auf-Pfeil (GJBOXCHAR) 

W_DNARROW (11): Ab-Pfeil (GJBOXCHAR) 

W_VSLIDE (12): Hintergrund für den vertikalen Slider (G_BOX) 

W_VELEV (13): Vertikaler Slider (G_BOX) 

WJHBAR (14): enthält die Elemente des horizontalen Balkens (G_BOX) 

W_LFARROW (15): Links-Pfeil (G_BOXCHAR) 

W_RTARROW (16): Rechts-Pfeil (G_BOXCHAR) 

W_HSLIDE (17): Hintergrund für den horizontalen Slider (G_BOX) 

WJHELEV (18): Horizontaler Slider (G_BOX) 

w2: Farbe für aktive Fenster (Farbwert wie etwa das untere 
Wort des “ob_spec” bei einem G_BOX-Objekt) oder -1 
(nicht setzen) 

w3: Farbe für inaktive Fenster (Farbwert wie etwa das untere 
Wort des “ob_spec” bei einem G_BOX-Objekt) oder -1 
(nicht setzen) 

WF_DCOLOR (19): Wie “WF_COLOR”, nur werden die Standardfarben für neu 

angelegte Fenster gesetzt (diese Aufgabe wird normalerweise 
von XCONTROL übernommen). 
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I WINDJFTND (AES 106) 


Ermittelt die Kennung des an einer bestimmten Koordinate befindlichen Fensters. 


Deklaration in C: 

WORD wind_find (WORD mx, WORD my) 
{ 

int_in[0] = mx; 
int_in[l] = my; 
return crys_if (106); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

1 Belegung 

contrl 

contrlfO] 

106 Opcode für W1ND_FIND 

contrl+2 

contrl[l] 

2 # Einträge in intjn 

contrl+4 

contrl [2J 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

0 # Einträge in addr_in 

contrl+8 

contrl|4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

mx 

int_in+2 

int_in[l] 

my 

int_out 

int_out[0] 

Return-Wert 


Parameter: 

mx, my: Bildschirmkoordinaten 

wind_find(): Kennung des gefundenen Fensters (-1: kein Fenster) 
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WINDUPDATE (AES107) 


Diese Funktion dient dazu, Bildschirmzugriffe verschiedener AES-Prozesse zu synchronisie¬ 
ren. 

BEG_UPDATE/END UPDATE 

Normalerweise ist jeder AES-Prozeß für die Inhalte der Arbeitsbereiche der von ihm 
geöffneten Fenster zuständig - der Rest des Bildschirms wird entweder vom Screen Manager 
oder anderen AES-Prozessen (zum Beispiel Accessories) verwaltet. 

Die Lage ändert sich beispielsweise, wenn man eine Dialogbox zeichnen will (generell: wenn 
man unter Umgehung der AES-Fensterfunktionen auf den Bildschirm zugreifen will, also 
auch beispielsweise beim Wiederherstellen eines Bildschirmausschnitts). In einem solchen 
Moment dürfen sich die von den Fenstern belegten Bildschirmflächen (mithin die Recht¬ 
ecklisten) nicht verändern - für wie lange, hält von der entsprechenden Operation ab. 

Mit “wind_update (BEG_UPDATE)” kann also ein Programm anmelden, daß es direkt auf 
dem Bildschirm ausgeben möchte, ohne dabei von anderen AES-Prozessen gestört zu werden. 
Die AES gehen dann so vor: Falls schon ein anderer Prozeß “wind_update (BEG_UPDATE)” 
ausgeführt hat, wird das betreffende Programm so lange blockiert, bis der Bildschirm wieder 
frei ist. Anderenfalls erhält man die Kontrolle zurück und darf bis zum “wind_update 
(ENDJUPDATE)” mit dem Bildschirm alles tun, was man möchte - Hauptsache, am Ende 
sind die Inhalte “fremder” Fenster wieder hergestellt. 

“wind_update()” dient mithin als Semaphore, die dafür sorgt, daß nur einer gleichzeitig auf 
dem Bildschirm malt. Das AES-Prozeßswitching wird dabei nicht unterbunden - es werden 
nur solche Prozesse blockiert, die selbst auch auf dem Bildschirm ausgeben wollen (und dies 
korrekt anmelden). Die Rechtecklisten der Fenster sind damit eingefroren (so daß man mit 
“wind_get()” in aller Ruhe die Liste der sichtbaren Rechtecke abrufen kann, ohne daß jemand 
anders dazwischenfunkt). Bei den Fensterfunktionen weiß GEM natürlich selbst Bescheid, 
daß sie zur Veränderung der Rechtecklisten führen können, und behandelt sie analog. Wann 
muß man also “wind_update (BEG_UPDATE)” benutzen? Immer dann, wenn man irgend¬ 
eine Änderung des Bildschirminhalts herbeiführt, ohne dabei die AES-Fensterfunktionen zu 
benutzen. 

BEG MCTRL/END MCTRL 

Die Verteilung der Mausereignisse und Tastaturereignisse wird folgendermaßen vorgenom¬ 
men: Mausereignisse gehen an den Prozeß, dem das betroffene Fenster gehört- vorausgesetzt, 
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ihm gehört auch das oberste Fenster. Ansonsten werden sie vom Screen Manager behandelt 
(zum Beispiel: Klick mit linker Maustaste auf nicht aktives Fenster führt zu WMJTOPPED- 
Mitteilung). Tastaturereignisse werden immer an den Prozeß, dem das aktive Fenster gehört, 
gemeldet. Dabei wird gegebenenfalls Hintergrundfenster 0 beachtet (falls kein anderes Fen¬ 
ster geöffnet ist). 

Mit “wind_.update (BEG_MCTRL)” kann man die Mauskontrolle selbst übernehmen. Diese 
Funktion wird immer dann benötigt, wenn Tastatur- oder Mauseingaben unabhängig von den 
geöffneten Fenstern bearbeitet werden sollen. Ein Beispiel dafür sind alle Funktion der GRAF- 
Bibliothek, insbesondere “graf_slidebox()” und auch die Dateiauswahlbox (die intern 
“graf_slidebox()” aufruft). 


Deklaration in C: 

WORD wind_update (WORD beg_update) 

{ 

int_in[0] = beg_update; 
return crys_if (107); 

1 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

107 

Opcode für WINDJJPDATE 

contrl+2 

contrl [1] 

1 

# Einträge in int_in 

contrl+4 

contrl [2] 

1 

# Einträge in int_out 

contrl+6 

contrl[3] 

0 

# Einträge in addrjn 

contrl+8 

contrl [4] 

0 

# Einträge in addr_out 

int_in 

int_in[0] 

beg_update 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 


Parameter: 

beg_update: Funktionsnummer: 

END_UPDATE (0): Bildschirmaufbau abgeschlossen. 

BEG_UPDATE (1): Bildschirmaufbau beginnt; 

Rechtecklisten werden eingefroren. 

ENDJMCTRL (2): Applikation gibt Mauskontrolle wieder ab. 
BEG_MCTRL (3): Applikation übernimmt totale Kontrolle über die Maus 
- insbesondere die Drop-Down-Menüs sind gesperrt. 
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WINDCALC (AES108) 


Berechnet entweder aus der Größe des Arbeitsbereiches eines Fensters die Gesamtmaße oder 
umgekehrt. 


Deklaration in C: 

WORD wind_calc (WORD wctype, WORD kind, WORD x, WORD y, WORD w, 
WORD h, WORD *px, WORD *py, WORD *pw, WORD *ph) 

{ 

int_in[0] = wctype; 
int_in[l] = kind; 
int_in[2] = x; 
int_in[3] = y; 
int_in[4] = w; 
int__in[5] = h; 
crys_if (108); 

*px t= int_out [1] ; 

*py ■» int_out 12 ] ; 

*pw = int_out[3]; 

*ph = int_out[4]; 
return int_out[0]; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

108 Opcode für WIND_CAlLC 

contrl+2 

contrl[I] 

6 # Einträge in int_in 

contrl+4 

contrl [2] 

5 # Einträge in int_out 

contrl+6 

contrl[3] 

0 # Einträge in addr Jn 

contrl+8 

contrl [4] 

0 # Einträge in addr_out 

intjn 

int_in[0] 

wctype 

int_in+2 

int_in[l] 

kind 

int_in+4 

int_in[2] 

X 

int.in+6 

int_in[3] 

y 

int_in+8 

int_in[4] 

w 

int_in+10 

int_in[5] 

h 
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Adresse 

Feldelement 

Belegung 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 

int_out+2 

int_outfl] 

px 

int._out+4 

int_out[2] 

py 

int_out+6 

int_out[3] 

pw 

int_out+8 

int_out[4] 

ph 


Parameter: 


wctype: 

kind: 


x, y,w, h: 

px, py, 

pw, ph: 


WC_BORDER (0): 

errechne Gesamtmaße 

WC_WORK (1): 

errechne Arbeitsbereich 

Komponenten des Fensters: 


NAME (0x0001): 

Titelbalken mit Name 

CLOSE (0x0002): 

Schließbox 

FULL (0x0004): 

Full-Box 

MOVE (0x0008): 

Bewegungsbox (Schattierung im Balken) 

INFO (0x0010): 

Info-Zeile 

SIZE (0x0020): 

Größen-Verstellung 

UP ARROW (0x0040): 

Pfeil nach oben 

DNARROW (0x0080): 

Pfeil nach unten 

VSLIDE (0x0100): 

vertikaler Schieber 

LFARROW (0x0200): 

Pfeil nach links 

RTARROW (0x0400): 

Pfeil nach rechts 

HSLIDE (0x0800): 

horizontaler Schieber 

Bekannte Koordinaten 


Errechnete Koordinaten 



Bemerkungen 

Man sollte niemals davon ausgehen, daß Fensterelemente eine bestimmte Größe oder Position 
haben, sondern statt dessen immer “wind_calc()” benutzen - dazu ist es schließlich da. Ein 
Beispiel: Es ist ohne weiteres denkbar, daß ein alternativer Bildschirmmanager alle Fensterränder 
breiter als “normal” darstellt. 
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WIND_NEW (AES109) - erst ab GEM 1.4 


Schließt und löscht alle Fenster (auch die der Accessories!) und setzt die mit “wind_update(>” 
gesetzten Blockierungen zurück. 


Deklaration in C: 

void windjnew (void) 
{ 

crys_if (109) ; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

109 

Opcode für WIND_NEW 

contrl+2 

contrl[l] 

0 

# Einträge in int_in 

contrl+4 

contrl [2] 

0 

# Einträge in int_out 

contrl+6 

contrl[3] 

0 

# Einträge in addrjn 

contrl+8 

contrl[4] 

0 

# Einträge in addr_out 
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RSRC-Funktionen 


RSRC_LOAD (AES110) 


Dient zum Laden und Initialisieren einer Resource-Datei. Dabei geschieht folgendes: 

1. Die Datei wird mittels “shel_find(>” gesucht. Gegebenenfalls wird ein Fehler gemeldet 

2. Aus dem Dateikopf wird die Länge der Datei ermittelt (siehe Beschreibung des RSC- 
Formats). 

3. Genausoviel Speicher wird mit “MallocO” alloziert. Falls nicht genügend Speicher da 
ist, wird ein Fehler gemeldet. 

4. Anfangsadresse und Länge in Bytes werden im global-Feld festgehalten (um dann für 
“rsrc_ftee()” bereitzustehen; dies ist von Atari nicht offiziell dokumentiert). 

5. Die Datei wird geöffnet, in voller Länge an die entsprechende Adresse geladen und 
wieder geschlossen. 

6. Nun werden noch einige Initialisierungen vorgenommen (Setzen der internen Zeiger, 
Anpassung der Koordinaten wie bei “rsrc_obfix()”, Setzen derTabelleder Objektbaum¬ 
zeiger, Setzen von global[5,6]). 

Was an dieser Stelle nicht passiert: die Umwandlung von Bitimages und Icons vom Standard¬ 
format in das geräteabhängige Format! 


Deklaration in C: 

WORD rsrc_load (const CHAR *rsname) 

{ 

addr_in[0] = rsnarae; 
return crys_if (110); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

110 Opcode für RSRCJLOAD 

contrl+2 

contrlf 1 ] 

0 # Einträge in int „in 
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Adresse 

Feldelement 

Belegung 

contrl+4 

contrl[2] 

1 

# Einträge in int_out 

contrl+6 

contrl[3] 

1 

# Einträge in addrjn 

contrl+8 

contrl[4] 

0 

# Einträge in addr_out 

addrjn 

addrjn [0] 

rsname 

int_out 

int_out[0] 

Retum-Wert (0: Fehler) 


Parameter: 

rsname: Dateiname der Resource-Datei (Datei wird über den Standardzugriffspfad des 

AES gesucht) 

Bemerkungen 

Ein Fehler kann verschiedene Ursachen haben: Speichermangel oder Resource-Datei nicht 
gefunden. 
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RSRC_FREE (AES 111) 


Gibt den durch “rsrc.Joad()” reservierten Speicherbereich wieder frei (sollte man am Ende 
eines Programmes auf gar keinen Fall vergessen). 


Deklaration in C: 

WORD rsrc_free (void) 

{ 

return crys_if (111); 

1 


GEM-Arrays; 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

111 

Opcode für RSRC_FREE 

contrl+2 

contrlf 1] 

0 

# Einträge in int „in 

contrl+4 

contrl [2] 

1 

# Einträge in int_out 

contrl+6 

contrl [3] 

0 

# Einträge in addr„in 

contrl+8 

contrl[4] 

0 

# Einträge in addr_out 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 
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RSRC QADDR (AES112) 


Ermittelt die Anfangsadresse einer Resource-Struktur im Speicher (nach “rsrc_load()”)- 


Deklaration in C: 

WORD rsrc_gaddr (WORD rstype, WORD rsid, void *paddr) 

{ 

int_in[0] = rstype; 
int_in[l] = rsid; 
control[4] = 1; 
crys_if (112); 
control[4] = 0; 

*paddr = addr__out [0] ; 
return int_out[0]; 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

112 Opcode für RSRC_GADDR 

contrl+2 

contrl[l] 

2 # Einträge in int_in 

contrl+4 

contrl [2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

0 # Einträge in addrjn 

contrl+8 

contrl[4] 

1 # Einträge in addr_out 

int_in 

int_in[0] 

rstype 

int_in+2 

int_in[l] 

rsid 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 

addr_out 

addr_out[0] 

paddr 


Parameter; 

rsid; Index (i) der gesuchten Struktur 
rstype; Typ der gesuchten Struktur: 

R_TREE (0): Zeiger auf Objektbaum i 

R_OBJECT (1): Zeiger auf Objektstruktur i 
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R_TEDINFO (2): 

Zeiger auf Textobjekt i 

RJCONBLK (3): 

Zeiger auf Icon i 

R_BITBLK (4): 

Zeiger auf Bit-Block i 

R_STRING (5): 

Zeiger auf String i 

R_IMAGEDATA (6): 

Zeiger auf Bilddaten Nr. i 

R.OBSPEC (7): 

Zeiger auf TEDINFO-Struktur 

R_TEPTEXT (8): 

Zeiger auf Text 

R_TEPTMPLT (9): 

Zeiger auf Textmaske 

R_TEP VALID (10): 

Zeiger auf Textschablone 

RJBPMASK(ll): 

Zeiger auf Icon-Maske 

RJBPDATA (12): 

Zeiger auf Icon-Daten 

R_IBPTEXT (13): 

Zeiger auf Icon-Text 

RJBIPDATA (14): 

Zeiger auf Bitmuster-Daten 

R_FRSTR (15): 

Adresse eines Zeigers auf freien String 

RJFR1MG (16): 

Adresse eines Zeigers auf freies Image 


paddr: Anfangsadresse der gesuchten Struktur 


Bemerkungen 

Wenn der Textzeiger innerhalb einer TEDINFO-Stmktur gesucht wird, muß selbstverständ¬ 
lich nicht die Nummer des zugehörigen Objekts, sondern die Nummer der TEDINFO-Struktur 
angegeben werden. Ähnliches gilt für die meisten anderen Codes. 
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RSRCjSADDR (AES113) 


Speichert die Anfangsadresse einer Datenstruktur im Speicher. 


Deklaration in C: 

WORD rsrc_saddr (WORD rstype, WORD rsid, void *lngval) 
{ 

int_in[0] = rstype; 
int_in[l] = rsid; 
addr_in[0] = lngval; 
return crys_if (113); 

} 

GEM-Arrays: 


Adresse 

Feldeiement 

Belegung 

contrl 

contrl [0] 

113 Opcode für RSRC_SADDR 

contrl+2 

contrl[l] 

2 # Einträge in int_in 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

l # Einträge in addr_in 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

rstype 

int_in+2 

int_in[l] 

rsid 

addr_in 

addr_in[0] 

lngval 

int_out 

int_out[0] 

Retum-Wert (0: Fehler) 


Parameter: 

rstype: Typ der Datenstruktur: 

R_FRSTR (15): Adresse eines Zeigers auf freien String 
R__FRIMG (16): Adresse eines Zeigers auf freies Image 
rsid: Position (i) in der Datenstruktur, in die lngval geschrieben wird 

lngval: die abzuspeichemde Adresse 
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RSRC_OBFIX (AES 114) 


Wandelt in einem Objekt die Koordinatendarstellung von Zeichen- in Pixeldarstellung. Dies 
ist immer dann vonnöten, wenn man Objekte nicht mit “rsrc Joad()” lädt, sondern direkt in 
das Programm eingliedert oder zur Laufzeit erzeugt. 

Dabei wird jeweils das untere Byte der Koordinatenangabe mit der Größe des Systemzeichen¬ 
satzes multipliziert und darauf das (vorzeichenbehaftete) obere Byte addiert. Ausnahme : Für 
eine Breite von genau 80 Zeichen wird die Breite des Bildschirms eingesetzt (was das 
Resource Construction Set beim Hintergrundobjekt des Menübaums nutzt). 

Deklaration in C: 

WORD rsrc_obfix (OBJECT *tree, WORD obj) 

{ 

addr_in[0] = t ree; 
int_in(0] = obj; 
return crys_if (114); 

1 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl(0] 

114 Opcode für RSRCJOBFIX 

contrl+2 

contrl[l] 

1 1 # Einträge in intjn 

contrl+4 

contri[2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

1 # Einträge in addr Jn 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

intjn 

int_in[0] 

obj 

addr_in 

addr_in[0] 

tree 

int_out 

int_out[0] 

Return-Wert (reserviert, immer 1) 


Parameter: 

obj: Objektnummer des zu konvertierenden Objekts 
tree: Anfangsadresse des Objektbaums 
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SHEL-Funktionen 


SHELJREAD (AES120) 


Liefert Namen und Kommandozeile, mit der die Applikation aufgerufen wurde. Dies klappt 
allerdings nur, wenn der Programmstart mit “shel_write()” vorgenommen wurde. Also im 
Zweifelsfall besser die Werte aus der Basepage verwenden. 

Deklaration in C: 

WORD shel_read (CHAR *pcmd, CHAR *ptail) 

{ 

addr_in[0] = pcmd; 
addr_in[1] = ptai1; 
return crys_if (120); 

> 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

120 Opcode für SHEL_READ 

contrl+2 

contrI[l] 

0 # Einträge in int_in 

contrl+4 

contrl [2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

2 # Einträge in addrjn 

contrl+8 

. contrl [4] 

0 # Einträge in addr_out 

addrjn 

addr_in[0] 

pcmd 

addrJn+4 

addr_in[l] 

ptail 

int_out 

int_put[0] 

Return-Wert (0: Fehler) 


Parameter: 

pcmd: Programmname mit Pfad (wie beim Aufruf mit “PexecO”) 
ptail: Kommandozeile (wie bei “PexecO" - also nullterminiert und mit Längenangabe im 
ersten Byte) 

Bemerkungen 

Beide Puffer sollten mindestens 128 Bytes lang sein! 
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SHELWROE (AES 121) 


Informiert die AES, daß eine andere Applikation gestartet werden soll. 

Im Gegensatz zum GEMDOS-Befehl “Pexec()” bleibt dabei das laufende Programm nicht 
resident. 

Ein Beispiel für die Verwendung dieser Funktion ist das Starten von “OUTPUT.APP” durch 
das Präsentationsgrafikprogramm “SciGraph”. 

Deklaration in C: 

WORD shel_write (WORD doex, WORD isgr, WORD isover, 

CHAR *pcmd, CHAR *ptail) 

{ 

int_in[0] = doex; 
int_in[l] = isgr; 
int_in[2] = isover; 
addr_in[0] = pcmd; 
addr_in[l] = ptail; 
return crys_if (121); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

121 Opcode für SHEL_WRITE 

contrl+2 

contrl[l] 

3 # Einträge in int_in 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl-f6 

contrl[3] 

2 # Einträge in addrjn 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

doex 

int_in+2 

int„in[l] 

isgr 

int_in+4 

int_in[2] 

isover 

addr_in 

addr_in[0] 

pcmd 

addr_in+4 

addr_in[l] 

ptail 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 
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Parameter: 


doex: 


isgr: 


isover: 


pcmd: 

ptail: 


0: keine weitere Applikation starten. Vor GEM 1,4 wurden dabei die AES 
komplett neu initialisiert (inkl. Laden der Accessories). Ab GEM 1.4 wird nor¬ 
mal zum Desktop zurückgekehrt. 

1: neues Programm laden 

0: keine Grafik-Applikation (Cursor wird ein-, Maus wird ausgeschaltet; Bild¬ 
schirm wird gelöscht) 

1: Grafik-Applikation 

in Atari-GEM unbenutzt (sollte auf 0 gesetzt werden). Unter PC-GEM läßt sich 
damit einstellen, ob das Programm als Overlay (0) oder erst nach Verlassen des 
aktuellen Programms (1) gestartet werden soll; Modus 2 erlaubt das Nachstarten 
unter Entfernung von GEM aus dem Speicher. 

Adresse eines Strings mit dem Namen des zu startenden Programms 
Adresse eines Strings mit der Kommandozeile 

(Vorsicht: genau wie bei “Pexec()” gibt das erste Byte die Länge der folgenden Zei¬ 
chenkette an.) 


Bemerkungen 

Beim Start von Programmen mittels “shel_write()” wird auch - je nach Applikationstyp - der 
entsprechende Critical-Error-Handler (siehe “etv_critic”) initialisiert. Wird eine TOS- 
Applikation von einem GEM-Programm mittels “PexecO” gestartet, braucht man sich also 
nicht darüber zu wundem, daß zwar Alertboxen erscheinen, aber keine Maus auftaucht. 
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SHELGET (AES122) 


Dient zum Lesen von Zeichen aus dem GEM-intemen Environment-Speicher. Das Desktop 
benutzt diesen Speicher zur Aufbewahrung der DESKTOP.INF-bzw. NE WDESK.INF-Datei 
(terminiert durch ASCII 26 (CTRL-Z) oder durch Null). Das Format dieser Datei ist allerdings 
nicht offiziell dokumentiert und kann sich ändern. 

Deklaration in C: 

WORD shel__get (CHAR *addr, WORD len) 

{ 

addr_in[0] = addr; 
int_in[0] = len;■ 
return crys_if (122) ; 

) 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl [0] 

122 Opcode für SHEL.GET 

contrl+2 

contrl[l] 

1 # Einträge in intjn 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrl[3] 

1 # Einträge in addr jn 

contrl+8 

contrl [4] 

0 # Einträge in addr_out 

intjn 

intjn[0] 

len 

addr_in 

addr_in[0] 

addr 

int_out 

int_out[0] 

Retum-Wert (0: Fehler) 


Parameter: 

len: Anzahl der zu lesenden Bytes 
addr: Anfangsadresse des Zielspeichers 
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’ SHEL_PUT (AES123) 


Schreibt eine gegebene Anzahl von Zeichen in die GEM-intemen Environment-Speicher. In 
älteren TOS-Versionen ist die Länge dieses Puffers auf 1024 Bytes beschränkt, ab GEM 1.4 
sollen 4096 Bytes hineinpassen. Da das Format dieses Puffers sowieso nicht offiziell 
dokumentiert ist, sollte man sich nicht den Kopf darüber zerbrechen... 

Deklaration in C: 

WORD shel__put (char *addr, WORD len) 

{ 

addr_in[0] = addr; 
int_in[0] = len; 
return crys_if (123)); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

123 Opcode für SHEL_PUT 

contrl+2 

contrl[l] 

1 # Einträge in intJn 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrI[3] 

1 # Einträge in addr_in 

contrl+8 

contrl [4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

len 

addr. .in 

addr_in[0] 

addr 

int_out 

int_out[0] 

Return-Wert (0: Fehler) 


Parameter: 

len: Anzahl der zu schreibenden Zeichen 
addr: Anfangsadresse des Puffers mit den Zeichen 
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SHELFINI) (AES124) 


Sucht eine Datei im aktuellen Verzeichnis und im Wurzelverzeichnis. Zusätzlich werden alle 
Verzeichnisse durchsucht, die in der AES-Environment-Variablen “PATFI=” angegeben sind, 
Im Normalfall handelt es sich dabei um das Wurzelverzeichnis des Bootlaufwerks und das 
aktuelle Verzeichnis. 

Ab GEM 1.4 wird auch der Pfad untersucht, in dem sich das gerade laufende Programm 
befindet (und der vor dem Programmnamen stehen sollte, den man mit “shel_read()” erfragen 
kann). Diese Funktion wird übrigens auch von der AES-Funktion “rsrc_load()” verwendet, um 
die Resource-Datei zu finden. 

Deklaration in C: 

WORD shel_find (char *ppath) 

{ 

addr_in[0] = ppath; 
return crys_if (124); 

} 

GEM-Arrays: 


Adresse 

1 Feldelement 

Belegung 

contrl 

contrl [0] 

124 

Opcode für SHEL_FIND 

contrl+2 

contrl[l] 

0 

# Einträge in intjn 

contrl+4 

contrl [2] 

1 

# Einträge in int_out 

contrl+6 

contrl [3] 

1 

# Einträge in addr_in 

contrl+8 

contrl[4] 

0 

# Einträge in addr_out 

addrin 

addr_in[0] 

ppath 


int_out 

int_out[0] 

Return-Wert (0: Fehler) 


Parameter: 

ppath: Adresse eines Strings mit dem Namen der gesuchten Datei. Nach Aufruf enthält er eine 
Dateispezifikation, wie sie von dem aktuellen Verzeichnis aus benutzt werden kann. 
Diese Datei Spezifikation kann natürlich auch einen vollständigen absoluten Pfad 
enthalten, daher sollte eine genügende Länge (mindestens 128 Zeichen!) gewählt wer¬ 
den. 
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SHELENVRN (AES 125) 


Was sind eigentlich die AES-Environment-Variablen, und wofür kann man sie einsetzen? 

Die Antwort ist wie so oft ganz einfach: Es sind tatsächlich nur die Environment-Variablen 
des Programms, das die AES beim Booten des Rechners aufgerufen hat. 

Genau wie bei den Environment-Variablen eines “normalen” GEMDOS-Programms handelt 
es sich um eine Liste von ASCII-Strings, in denen die verschiedenen Variablennamen und 
deren Werte festgehalten sind. 

Wie so oft bei Environment-Strings ist die sogenannte “PATH”-Variable die wichtigste. Sie 
gibt einfach eine Liste von Verzeichnissen an, in denen nach bestimmten Dateien gesucht 
werden soll. Als Trennzeichen dienen Kommata (ab AES-Version 1.4) und Strichpunkte 
(schon immer). Auch leere Einträge sind erlaubt und stehen für das aktuelle Verzeichnis 
(“;C:\” steht also für das Wurzelverzeichnis von C: und das aktuelle Verzeichnis). 

Nun kann man natürlich außer der Pfadvariablen noch frei nach Gutdünken weitere Variablen 
setzen. Diese Variablen kann man dann nicht nur mit der AES-Funktion “shel_envmO” 
abfragen, sondern sie werden auch vom Desktop an alle gestarteten Programme als normale 
GEMDOS-Environment-Variablen weitergereicht. 

Naheliegend ist es beispielsweise, den Standardsuchpfad um einen Ordner zu erweitern, in 
dem man alle Resource-Dateien sammelt. Damit werden die Verzeichnisse auf der Festplatte 
deutlich übersichtlicher. Nachteil: Leider vergißt man zu oft beim Weitergeben von Program¬ 
men den Resource-File. 

Jetzt ein Beispiel für das Hinzufügen neuer Environment-Variablen: Turbo-C beispielsweise 
sucht beim Öffnen seiner Help-Datei nach der Environment-Variablen “TC”. Falls vorhan¬ 
den, wird die Help-Datei im darin angegebenen Ordner gesucht. Damit ist es nicht notwendig, 
die Help-Datei im gleichen Ordner wie Turbo-C zu installieren. 

Das BIOS installiert normalerweise als Standardpfad einfach das Wurzelverzeichnis des 
Bootlaufwerks. Dazu verwendet es die Systemvariable “_bootdev” und begeht dabei unglück¬ 
licherweise einen seit langem bekannten Fehler: es betrachtet die Systemvariable als Byte statt 
als Wort und greift damit auf die falsche Speicherzelle zu. 

Resultat: Als Standardpfad wird “A:\” eingetragen - ungeachtet, von welchem Laufwerk man 
gebootet hat. Die meisten Harddisktreiber von Fremdherstellem umschiffen dieses Problem 
auf die eine oder andere Weise. 
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Und dann ist da noch ein anderes Problem: Leider setzt das BIOS das Environment auf eine 
andere Art und Weise als der ganze Rest der Computerwelt. Normalerweise handelt es sich 
bei den Environmentstrings um nullterminierte Zeichenketten derForm “VARIABLE^ WERT”. 
Das Ende wird demzufolge durcheinedoppelteNull angegeben. Anders beimBIOS, das leider 
hinter der Zeichenkette “PATH=” eine Null einfügt. 

Von Atari dokumentierte Abhilfe: Wenn der für “PATH=” zurückgelieferte Zeiger auf ein 
Nullbyte zeigt, sollte man ihn um eins erhöhen, um an das richtige Ergebnis zu kommen. 


Deklaration in C: 

WORD shel_envrn (char *ppath, char *psrch) 
{ 

addr_in[0] = ppath; 
addr_in[l] = psrch; 
return crys_if (125); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

125 Opcode für SHEL_ENVRN 

contrl+2 

contrl[l] 

0 # Einträge in int_in 

contrl+4 

contrl [2] 

1 # Einträge in int_out 

contrl+6 

contrl [3] 

2 # Einträge in addrjn 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

addr_in 

addr_in[0] 

ppath 

addr_in+4 

addr_in[l] 

psrch 

int_out 

int_out[0] 

reserviert (immer 1) 


Bemerkungen 

Um das AES-Environment zu ändern, hängt man sich am besten in den Systerovektor 
“exec_os”, über den GEM gestartet wird. In der aufgerufenen Routine liegt - wie bei einem 
Programm - der Basepage-Zeiger auf dem Stack. In die dort angegebene Basepage setzt man 
dann einfach den Zeiger auf das neue Environment ein (vor GEM 1.4 wurden freilich nur die 
ersten 50 Bytes übernommen!). 
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SHELRDEF (AES 126) nur in PC-GEM ab Version 2.0 


Hiermit kann man abfragen, welches Programm nach Beendigung des aktuellen gestartet wird 
(sollte im allgemeinen das Desktop sein). 

Deklaration in C: 

WORD shel_rdef (CHAR *lpcmd, CHAR *lpdir) 

{ 

addr_in[0] = lpcmd; 
addr_in[l] = lpdir; 
return crys__if (126); 

} 

GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

126 Opcode für SHELJRDEF 

contrl+2 

contrl[l] 

0 # Einträge in int_in 

contrl+4 

contrl[2] 

1 # Einträge in int_out 

contrl+6 

contrl [3] 

2 # Einträge in addrjn 

contrl+8 

contrl[4] 

0 # Einträge in addr_out 

addr_in 

addr_in[0] 

lpcmd 

addr_in+4 

addr_in[l] 

lpdir 

int_out 

int_out[0] 

Return-Wert (Undefiniert) 
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| SHEL_WDEF (AES 127) - nur in PC-GEM ab Version 2.0 


Analog zu “shel_rdef()” kann man mit dieser Funktion die “Default-Applikation” festlegen. 


Deklaration in C: 

WORD shel_wdef (CHAR *lpcmd, CHÄR *lpdir) 
{ 

addrjn [0] = lpcmd; 
addr_in[l] = lpdir; 


return crys_if (127); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

contrl 

contrl [0] 

contrl+2 

contrl [1] 

contrl+4 

contrl [2] 

contrl+6 

contrl[3] 

contrl+8 

contrl[4] 

addr.in 

addrjn [0] 

addr_in+4 

addrjn[l] 

int_out 

int_out[l] 


Belegung 


127 Opcode für SHEL_WDEF 
0 # Einträge in intjn 

0 # Einträge in int_out 

2 # Einträge in addrjn 

0 # Einträge in addr_out 

lpcmd 

lpdir 

Retum-Wert (Undefiniert) 
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XGRF-Funküonen 


XGRF_STEPCALC (AES130) - nur in PC-GEM ab Version 2.0 


Mit dieser Funktion kann man sich alle Parameter für einen “xgrf_2box()”-Auffuf berechnen 
lassen. 

Aus Anfangsgröße, Endgröße und Endposition des Rechtecks werden Endposition, Anzahl 
der Schritte und Größe der Schritte bestimmt. 


Deklaration in C: 

WORD xgrf_stepcalc (WORD orgw, WORD orgh, WORD xc, WORD yc, WORD w, 
WORD h, WORD *pcx, WORD *pcy, WORD *pcnt, 

WORD *pxstep, WORD *pystep) 

{ 

int_in[0] = orgw; 
int_in[l] = orgh; 
int in[2] = xc; 
int__in[3] = yc; 
int_in[4] = w; 

int_in[5] = y; 
crys_if (130); 

*pcx = int_out[l]; 

*pcy = int_out[2]; 

*pcnt = int_out[3]; 

*pxstep == int_out[4]; 

*pystep = int__out[5]; 
return int^out[0]; 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

130 

Opcode für XGRF_STEPCALC 

contrl+2 

contrlfl] 

6 

# Einträge in int_in 

contrl+4 

contrl[2] 

6 

# Einträge in int_out 

contrl+6 

contrl[3] 

0 

# Einträge in addr_in 

contrl+8 

contrl [4] 

0 

# Einträge in addr_out 
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Adresse 

Feldelement 

Belegung 

intjn 

int_in[0] 

orgw 

int_in+2 

int_in[l] 

orgh 

int_in+4 

intjn[2] 

xc 

int_in+6 

int_in[3] 

yc 

intJn+8 

int_in[4] 

w 

int_in+10 

int_in[5] 

h 

int_out 

int„out[0] 

Return-Wert (0: Fehler) 

int_out+2 

int_out[l] 

pcx 

int_out+4 

int_out[2] 

pcy 

int„out+6 

int_out[3] 

pcnt 

int_out+8 

int_out[4] 

pxstep 

int_out+10 

int_out[5] 

pystep 


Parameter: 


orgw: 
orgh: 
xc, yc: 
w, h: 
pcx, pcy: 
pcnt: 
pxstep, 
pystep: 


anfängliche Breite 
anfängliche Höhe 
Endposition 
Endgröße 

zentrierte Position nach Ablauf des Vorgangs 
Anzahl der Einzelschritte 

Schrittweite in X- und Y-Richtung pro Einzelschritt 
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XGRF 2BOX (AES 131) - nur in PC-GEM ab Version 2.0 


Zeichnet eine Reihe von Rechtecken, die sich über den Bildschirm bewegen (dies ist ein Ersatz 
für die in PC-GEM 2.0 gestrichenen Funktionen der FORM- und GRAF-Bibliotheken). 


Deklaration in C: 

WORD xgrf_2box (WORD xc, WORD yc, WORD w, WORD h, WORD cornes, 
WORD ent, WORD xstep, WORD ystep, WORD doübled) 

{ 

int_in[0] = ent; 
int_in[l] = xstep; 
int_in[2] = ystep; 
int_in[3] = doubled; 
int_in[4] = corners; 
int_in[5] = xc; 
int_in[6] = yc; 
int_in[7] = w; 
int_in[8] = h; 
return crys_if (131); 

} 


GEM-Arrays: 


Adresse 

Feldelement 

Belegung 

contrl 

contrl[0] 

131 Opcode für XGRF_2BOX 

contrl+2 

contrl[l] 

9 # Einträge in intjn 

contri+4 

contrl[2] 

1 # Einträge in int ..out 

contrl+6 

contrl[3] 

0 # Einträge in addrjn 

contrl-t-8 

contrl [4] 

0 # Einträge in addr_out 

int_in 

int_in[0] 

ent 

int_in+2 

intjn[l] 

xstep 

int_in+4 

intin[2] 

ystep 

int_in+6 

int_in[3] 

doubled 

int_in+8 

int_in[4] 

corners 

int_in+10 

int_in[5] 

xc 

int_in+12 

int_in[6] 

yc 

int_in+I4 

int„in[7] 

w 
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Adresse 

Feldelement 

Belegung 

int_in+16 

int_in[8] 

h 

int_out 

int_out[0] 

Return-Wert 


Parameter: 


ent: 

xstep, ystep: 
doubled: 

comers: 

xc, yc: 
w, h: 


Anzahl der Einzelschritte 
Schrittweite in X- und Y-Richtung 
0: normale Schrittweite 
1: Schrittweite verdoppeln 
0: ganze Rechtecke zeichnen 
1: nur die Ecken zeichnen 
Anfangsposition 
Anfangsgröße 
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Kapitel 5: XCONTROL 


Einleitung 

XControl ist das Kontrollfeld, das dem Atari TT und dem Mega STE seit Ende 1990 beigelegt 
wird. Es ist modular aufgebaut und kann erweitert werden. Die Module sind Dateien, deren 
Namenserweiterung “CPX” (Control Panel eXtension) heißt. XControl ist also nichts anderes 
als ein Steuerungsprogramm für solche Module, die im wesentlichen Konfigurationsdialoge 
sein sollten. Für andere Zwecke sollte man XControl nicht mißbrauchen. 

Die Kommunikation zwischen XControl und den einzelnen Modulen erfolgt über zwei 
Strukturen. In der einen (XCPB) macht XControl einige Flags und eine ganze Reihe von 
Hilfsfunktionen zugänglich. Jede CPX wiederum liefert eine CPXINFO-Struktur mit 
Funktionszeigem zurück. 

XControl lädt beim Start alle verfügbaren CPX-Header. Während des Bootvorgangs werden 
alle CPX-Dateien einmal zum Initialisieren aufgerufen, sofern im Header ein entsprechendes 
Flag gesetzt ist. Bei jeder Aktivierung wird die Initialisierungsroutine des CPX-Moduls 
aufgerufen, wobei dann ein Zeiger auf eine CPXINFO-Struktur zurückzuliefem ist. 

Für jedes einzelne Modul kann spezifiziert werden, ob es resident geladen werden soll (diese 
Eigenschaft kann man auch mittels der mitgelieferten Konfigurations-CPX ändern). Solche 
Module werden gleich beim Laden vollständig geladen und bleiben dann resident - wohl ein 
Zugeständnis für die Benutzer, bei denen die XControl-Module auf einer Diskette odereiner 
langsamen Festplatte liegen. Ebenso ist es möglich, CPX-Module zu schreiben, die nur be¬ 
stimmte Werte setzen (“set-only”). Derartige CPX-Module geben bei der Initialisierung ein¬ 
fach einen Nullzeiger zurück. Sie werden nur beim Booten bzw. beim erneuten Laden der 
Module durch XControl aufgerufen. 

XControl verwendet “evnt_multi()” für die eigene Verwaltung und die der CPX-Module. 
Wird ein CPX-Modul vom Anwender ausgewählt, so lädt XControl dieses in den Speicher und 
ruft “cpxjnit()” auf. Anschließend wird die Funktion “cpx_call()” aufgerufen, wobei im we¬ 
sentlichen nun das CPX-Modul die Steuerung übernimmt. Es existieren zwei Arten von CPX- 
Modulen: Form-CPX und Event-CPX. 

Form-CPX sind relativ einfach zu programmieren, bieten jedoch nur eine eingeschränkte 
Flexibilität. Event-CPX bieten mehr Flexibilität, da sie die AES-Events direkt verwerten. Alle 
mit XControl 1.0 ausgelieferten CPX-Module sind Form-CPX-Dateien. Dies zeigt, daß es in 
den meisten Fällen ausreicht, Form-CPX zu benutzen. 
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CPX-Format 

Bevor wir zur Programmierung der CPX-Dateien übergehen, wollen wir das Dateiformat und 
die Terminologie näher betrachten. 

Der Aufbau der CPX-Datei ist einem normalen Programm sehr ähnlich. Sie besteht aus einem 
512 Byte großen Header und dem übrigen Dateiinhalt, bei dem es sich fast um eine normale 
GEMDOS-Programmdatei handelt. 


Header (512 Byte) 


GEMDOS-Programmheader 


Text-Segment 


Data-Segment 


Relozierungsinformationen 


Der Aufbau des Headers selbst: 


typedef struct 
{ 

UWORD magic; /* = 100 */ 

struct 
{ 


unsigned reserved 

: 13; 

/* reserviert */ 

unsigned resident 

: 1; 

/* RAM-resident */ 

unsigned bootinit 

: 1; 

/* Boot-Initialisierung */ 

unsigned setonly 

: 1; 

/* Set-Only */ 

) flags; 



LONG cpx id; 

/* 

eindeutige CPX-ID */ 

DWORD cpx_version; 

/* 

CPX-Versionsnurraner */ 

char i_text[14); 

/* 

Icontext */ 

UWORD sm_icon[48];. 

/* 

Bitmap (32 x 24 Pixel) */ 

UWORD i_color; 

/* 

Iconfarbe */ 
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char 

title_text[18]; 

/* Name */ 

UWORD 

t__color; 

/* Textfärbe */ 

char 

buffer[64]; 

/* nicht flüchtiger Puffer */ 

char 

reserved[306]; 

/* reserviert */ 

} CPXHEAD; 



Bemerkungen 




- Die erste Funktion im Textsegment muß die Initialisierungsroutine für die CPX sein 
(siehe Definition von “cpxjnitö”). 

- Zur Konstruktion solcher Header ist für eingetragene Entwickler bei Atari ein spezielles 
Tool erhältlich. 

- Header und gelinkte Programmdatei können in den meisten UNIX-ähnlichen Shells mit 
dem Kommando “cat” zusammengefügt werden. 

- Bei der CPX-Entwicklung ist es sehr praktisch, daß man XControl auch als Programm 
starten kann (einfach von “XCONTROL.ACC” in “XCONTROL.APP” umbenennen). 
So kommt man um ein permanentes Neu-Booten des Rechners herum. 

- CPX-ID und -Versionsnummer sorgen dafür, daß jede CPX nur ein einziges Mal - und 
auch nur die neueste Version - erscheint. 

Die offizielle Terminologie für die Dateinamen ist: 


Namenserweiterung 

Dateityp 

*.CPX 

Standard-CPX-Datei, fertig zum Gebrauch 

*.CP 

Standard-CPX-Datei ohne Header 

*_R.CPX 

residente CPX-Datei 

*_S.CPX 

set-only CPX-Datei 

*.HDR 

Header für CPX-Datei 

*.CPZ 

inaktive CPX-Datei (von XControl deaktiviert) 


Programmierrichtlmien 

In diesem Zusammenhang auch einige Grundregeln, die bei der Programmierung von CPX- 
Modulen beachtet werden sollen: 
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- Reservierter Speicher ist möglichst schnell wieder freizugeben. 

- XControl-Funktionen sind immer auszunutzen, wenn dies möglich ist. 

- Die Benutzerschnittstelle ist einfach und in Anlehnung an die anderen CPX-Module zu 
gestalten. 

Grafische Elemente sind Menükommandos vorzuziehen. 

- “OK” und “Abbruch”/“Cancel” sind - sofern nötig - immer zu implementieren. Hierbei 
heißt es “OK” (nicht “Ok”)und“Abbruch”/‘Cancel”(njc/it“ABBRUCH”/’ , CANCEL”). 

- Popup-Menüs sind als Text mit schattiertem Rechteck darzustellen. 

- AC_CLOSE - das Verlassen des Hauptprogramms - wird als “Abbruch” gewertet. 

- WM_CLOSE - das Schließen des XControl-Fensters - wird als “OK” gewertet. 

- “Säve”/”Sichem” ist als “OK” ohne Verlassen des Dialogs zu betrachten. 

- Das Wurzelobjekt der CPX hat immer eine Größe von 256 x 176 Pixeln. 

- Interrupt-Vektoren dürfen nicht verändert werden. 

- “Xform_do()” darf nicht mit Funktionen für Event-CPX vermischt werden. 

- Reservierter Speicher darf beim Verlassen der CPX nicht vergessen werden, da es sonst 
zu einer Speicherfragmentierung kommt. 

Bereits von anderen CPX verwandte IDs dürfen nicht mehr benutzt werden. 

- Geöffnete Dateien müssen auf jeden Fall wieder geschlossen werden. 

- Geöffnete VDI-Workstations sind auf jeden Fall wieder zu schließen (spätestens bei 
AC_CLOSE/WM_CLOSE!>, wenn sie nicht mehr benötigt werden. 

Nun zur Programmierung eines CPX-Moduls selbst. Da ein CPX-Modul - mit Ausnahme von 
64 Byte - über keinen nicht-vergänglichen Speicher verfügt, ist nichts erlaubt, was Speicher 
in irgendeiner Form fest reserviert. Variableninhalte gehen mit dem Verlassen des CPX- 
Moduls in der Regel verloren! Eine Folge dieser Tatsache ist zum Beispiel, daß Resourcen 
statisch eingebunden werden müssen, Speicheranforderungen nur kurzzeitig erfolgen dürfen 
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und keine virtuellen VDI-Workstations (wg. der internen Speicheranforderung) dauerhaft 
angelegt werden. 

Ein Beispiel-CPX 

Nehmen wir als Beispiel ein ganz einfaches, aber lauffähiges CPX-Modul: 

/* sample.c */ 

/* Entwickelt mit Turbo C. */ 

#include <aes.h> /* AES */ 

#include <stddef.h> /* Standard-Definitionen */ 

finclude <cpxdata.h> /* CPX-Datenstrukturen */ 

/* Prototypen */ 

CPXINFO* cdecl cpx_init(XCPB *Xcpb); 

WORD cdecl cpx_call(GRECT *rect); 

/* CPX-Strukturen */ 

XCPB *xcpb; /* XControl Parameter Block */ 

CPXINFO cpxinfo = /* CPX Information Structure */ 

{ 

cpx_call, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL 

}; 

/* Resourcen/einfache Dialogbox */ 
tdefine BOK 2 

#define NUMjOBS 3 

OBJECT tree[] = 

1 

( 

-1, 1, BOK, 

G_BOX, NONE, NORMAL, 

(long) OxOOllOlL, 

0x0000, 0x0000, 0x0020, 0x000b 

}, 

1 

BOK, -1, -1, 

G_STRING, NONE, NORMAL, 

(long) "Beispiel", 

0x000c, 0x0004, 0x0008, 0x0001 
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f 

0 , - 1 , - 1 , 

GJ3UTT0N, LASTOB | EXIT | DEFAULT | SELECTABLE, 
NORMAL, 

(long) "OK", 

0x0002, 0x0009, 0x0007, 0x0001 

} 


/* der Initialisierungsaufruf */ 

CPXINFO * cdecl cpx_init (XCPB *Xcpb) 

{ 

MORD i; 
xcpb = Xcpb; 

/* Bootvorgang? Dann Ende und anz'eigen, daß die CPX 
erscheinen soll, also nicht 'set-only' ist... */ 
if (xcpb->booting) return ((CPXINFO *) 1) ; 

/* Resourcen fixiert? */ 
if (!xcpb->SkipRshFix) 

for (i =0; i < NUM_OBS; i++) 

(*xcpb->rsh_obfix)(tree, i); 
return &cpxinfo; 

} 

/* der eigentliche Aufruf des CPX-Moduls */ 

WORD cdecl cpx_call (GRECT *rect) 

{ 

WORD msg[8]; 

/* Dialogbox anpassen */ 
tree[ROOT] .ob_x = rect->g_x; 
tree[ROOT],ob_y = rect->g_y; 

/* Dialogbox ausgeben */ 
objc_draw (tree, ROOT, MAX_DEPTH, 

rect->g_x, rect~>g_y, rect->g_w, rect->g_h); 
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/* Dialog durchführen */ 
(*xcpb->Xform_do)(tree, 0, msg); 

/* fertig! */ 
return 0; 

} 

Ferner wird ein kleines Assemblermodul benötigt. 

; cpxstart.s 


; Startup-Datei für CPX-Module 
/ 

.globl cpxstart 

.g1obl save_vars 

.globl cpx_init 

• text 
cpxstart: 

jmp cpx_init 

.data 

; Speicherbereich für Default-Einstellungen 
; {muß ggf. angepaßt werden) 
save_vars: 

. de. w 0 

.end 

Mit der folgenden Projektdatei wird das CPX-Modul in Turbo C übersetzt: 

SAMPLE.CP 

CPXSTART.S 
SAMPLE.C 
TCSTDLIB.LIB 
TCGEMLIB.LIB 
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Definitionen und Strukturen 

Nun haben Sie einen Einblick in den Aufbau eines CPX-Moduls gewonnen. Es bleibt noch, 
die Strukturen CPXINFO und XCPB sowie alle dazugehörigen Definitionen zu erklären: 

/* cpxdata.h */ 
typedef struct 
{ 

WORD x; 

WORD y; 

WORD buttons; 

WORD kstate; 

} MRETS; 

typedef struct 

( 

WORD handle; /* aus graf_handle ()-Aufruf von 

XControl. Wichtig für v_opnvwk() ! */ 
WORD booting; /* ungl. 0: Initialisierg./Bootvorg. */ 

WORD reserved; /* reserviert */ 

WORD SkipRshFix;/* ungleich: Resourcekoordinaten bereits 

transformiert */ 

void *reservel; /* reserviert */ 

void *reserve2; /* reserviert */ 

void cdecl (*rsh_fix)(WORD num_objs, WORD num_frstr, 

WORD num_frimg, WORD num_tree, 

OBJECT *rs_object, TEDINFO *rs_tedinfo, 
char *rs_strings[], ICONBLK *rs__iconblk, 
BITBLK *rs_bitblk, long *rs_frstr, 
long *rs_frimg, long *rs_trindex, 
struct foobar *rs__imdope) ; 

void cdecl (*rsh_obfix)(OBJECT *tree, WORD curob); 

WORD cdecl (*Popup)(char *items[], WORD numitems, 

WORD default_item, WORD font_size, 

GRECT *button, GRECT *world); 
void cdecl (*Sl_size)(OBJECT *tree, WORD base, 

WORD slider, WORD num_items, WORD visible, 

WORD direction, WORD rrrin_size) ; 
void cdecl (*Sl_x)(OBJECT *tree, WORD base, WORD slider, 
WORD value, WORD numjnin, WORD num_inax, 
void (*foo)(void)); 
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void cdecl 


void cdecl 


void cdecl 


void cdecl 


WORD cdecl 

GRECT * cdecl 
GRECT * cdecl 
void cdecl 

WORD cdecl 
WORD cdecl 
void * cdecl 
WORD cdecl 
WORD 


void cdecl 
} XCPB; 

typedef struct 

{ 

WORD cdecl 
void cdecl 
void cdecl 
void cdecl 
void cdecl 
void cdecl 
void cdecl 
void cdecl 


(*Sl_y)(OBJECT *tree, WORD base, WORD slider, 
WORD value, WORD num_rnin, WORD numjmax, 
void (*foo)(void)); 

(*Sl_arrow)(OBJECT *tree, WORD base, 

WORD slider, WORD obj, WORD inc, WORD min, 
WORD max, WORD *numvar, WORD direction, 
void (*foo)(void)); 

(*Sl_dragx)(OBJECT *tree, WORD base, 

WORD slider, WORD min, WORD max, 

WORD *numvar, void (*foo)(void)); 

(*Sl_dragy)(OBJECT *tree, WORD base, 

WORD slider, WORD min, WORD max, 

WORD *numvar, void (*foo)(void)); 

(*Xform__do)(OBJECT *tree, WORD start_field, 
WORD *puntmsg); 

(*GetFirstRect)(GRECT *prect); 

(*GetNextRect)(void); 

(*Set_Evnt_Mask)(WORD mask, MOBLK *ml, 

MOBLK *m2, long time); 

(*XGen_Alert)(WORD id); 

(*CPX_Save) (void *ptr, long num); 

(*Get_Buffer)(void); 

(*getcookie)(long cookie, long *p_value); 
Country_Code; 

/* Länderkennung, analog zu der im 
OSHEADER - allerdings in fester 
Abhängigkeit von der XControl-Version */ 
(*MFsave)(WORD saveit, MFORM *mf); 


(*cpx_call)(GRECT *work); 

(*cpx_draw)(GRECT *clip); 

(*cpx_wmove)(GRECT *work); 

(*cpx_timer)(WORD *event); 

(*cpx_key)(WORD kstate, WORD key, WORD *event); 
(*cpx_button)(MRETS *mrets, WORD *event); 
(*cpx_ml)(MRETS *mrets, WORD *event); 

(*cpx_m2)(MRETS *mrets, WORD *event); 
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WORD cdecl 

void cdecl 
} CPXINFO; 


(*cpx_hook)(WORD event, WORD *msg, MRETS 
*mrets,WORD *key, WORD *nclicks); 
(*cpx_close)(WORD flag); 


Idefine VERT1CAL 0 

#define HORIZONTAL 1 

#define SAVE_DEFAULTS 0 
#define MEM_ERR 1 

#define FILE_ERR 2 

#define FILE_NOT_FOUND 3 

Idefine MFSAVE 1 

#define MFRESTORE 0 


/* zusätzliche Definition für Xform_do() */ 
#define CT KEY 53 
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Von der CPX bereitgestellte Funktionen 


cpxinit (Intitialisierung) 


Diese Funktion muß am Beginn des Textsegments derCPX-Datei stehen (nun ja, zumindest 
ein Sprungbefehl zu ihrem Anfang) und wird während der XControl-Initialisierung sowie 
beim Aktivieren der CPX aufgerufen. 

Als Parameter erhält sie einen Zeiger auf die oben definierte XCPB-Struktur. Als Resultat lie¬ 
fert man einen Zeiger auf die eigene CPXINFO-Struktur oder einen Nullzeiger zurück. 


Deklaration in C: 

CPXINFO * cdecl cpx_init (XCPB *xcpb); 

Eingabe-Parameter: 

xcpb: Zeiger auf die XCPB-Struktur von XControl 


Ausgabe-Parameter: 

NULL: Es handelt sich um eine “set-only” CPX. 

sonst: Zeiger auf die CPXINFO-Struktur der CPX (oder während des Bootens: 

irgendein Wert ungleich Null, um anzuzeigen, daß XControl die CPX in die 
Liste der aktivierbaren CPXe aufnehmen soll). 
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Funktionen aus CPXINFO 


cpx_call (Aktivierungsroutine) 


Quasi das Hauptprogramm des CPX-Moduls. “cpx_call()” wird nach “cpx_init()” aufgerufen, 
wenn der Anwender das entsprechende Modul ausgewählt hat. Als Übergabeparameter erhält 
man die Koordinaten der Arbeitsfläche im XControl-Fenster. Somit läßt sich zum Beispiel die 
Dialogbox passend plazieren. 


Deklaration in C: 

WORD cdecl (*cpx_call)(GRECT *work); 


Eingabe-Parameter: 

work: Rechteck mit den Koordinaten des XControl-Fensters 


Ausgabe-Parameter: 

0: Ende der Bearbeitung 

sonst: CPX soll weiterbearbeitet werden 
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Event-Handling-Routinen aus CPXINFO (nur für Event-CPX) 
cpxdraw (Redraw-Ereignis) ~j 

Diese Routine wird aufgerufen, wenn ein CPX-Modul aktiv ist und XControl ein Redraw 
benötigt. Die nötige Rechtecldiste ist mit “GetFirstRect()” und “GetNextRectO” abzurufen. 

Deklaration in C: 

void cdecl (*cpx_draw)(GRECT *clip); 

Eingabe-Parameter: 

ciip: neu zu zeichnender Bereich, der auch als Übergabeparameter für “GetFirstRect()” 
benötigt wird. 


1 cpxwmove (Fensterverschiebung) 

“cpx_wmove()” wird aufgerufen, wenn der Anwender das XControl-Fenster bewegt. 

Deklaration in C: 

void cdecl (*cpx_wmove)(GRECT *work); 

Eingabe-Parameter: 

work: neue Fenster-Koordinaten 
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cpxtimer (Timer-Event) 

. ! 


Die Funktion wird aufgerufen, wenn ein Timer-Event aufgetreten ist. Timer-Events werden 
von Form-CPX nicht unterstützt. 

Deklaration in C: 

void cdecl (*cpx_timer)(WORD *event); 

Ausgabe-Parameter: 

event: auf 1 setzen, wenn die CPX verlassen werden soll; ansonsten ignorieren 


cpxkey (Keyboard-Event) 

“cpx_key()” wird aufgerufen, wenn ein Keyboard-Event aufgetreten ist. 

Deklaration in C: 

void cdecl (*cpx_key)(WORD kstate, WORD key, WORD *event); 

Eingabe-Parameter: 

kstate: Status der Umschalttasten (Altemate, Control, Shift etc.) 

key: enthält im Highbyte den Scancode und im Lowbyte den ASCII-Code (sofern 

vorhanden) der gedrückten Taste 

Ausgabe-Parameter: 

event: auf 1 setzen, wenn die CPX verlassen werden soll; ansonsten ignorieren 
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cpx_button (Maustasten-Event) 

Die Funktion wird bei einem aufgetretenen Maustasten-Event aufgerufen. 

Deklaration in C: 

void cdecl (*cpx_button)(MRETS *mrets, WORD nclicks, WORD *event); 

Eingabe-Parameter: 

mrets: Parameter der Maus, die zu diesem Event gehören 

nclicks: Anzahl der Mausklicks 

Ausgabe-Parameter: 

event: auf 1 setzen, wenn die CPX verlassen werden soll; ansonsten ignorieren 


cpxjml, cpx_tn2 (Mausrechteck-Event) 

“cpx_ml()” bzw. “cpx_m2()” werden dann aufgerufen, wenn der Mauszeiger bestimmte 
Rechtecke betritt oder verläßt. 

Deklaration in C; 

void cdecl (*cpx__ml)(MRETS *mrets, WORD *event); 
void cdecl (*cpx_m2)(MRETS *mrets, WORD *event); 

Eingabe-Parameter: 

mrets: Parameter der Maus, die zu diesem Event gehören 

Ausgabe-Parameter: 

event: auf 1 setzen, wenn die CPX verlassen werden soll; ansonsten ignorieren 
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cpxhook (Preemption Hook) 


Die Funktion wird sofort nach “evnt_multi()” aufgerufen, also noch bevor XControl das Event 
verarbeitet. 

Deklaration in C: 

WORD cdecl <*cpx_hook) (WORD event, WORD *msg, MRETS *mrets, 

WORD *key, WORD *nclicks); 


Eingabe-Parameter: 

event: aufgetretene Events 

msg: Ereignispuffer 

mrets: Mausparameter 

key: Tastendruck 

nclicks: Anzahl der Mausklicks 


Ausgabe-Parameter: 

0: Eventverarbeitung fortsetzen 

sonst: Eventverarbeitung abbrechen 


- --- ’ ----! 

cpxelose (Close-Event) 

_I 


“cpx_close()” wird bei jeder AC_CLOSE- und jeder WM_CLOSE-Message aufgerufen. Die 
CPX muß dann sofort allen reservierten Speicher (“MallocO”, "v_opnvwk()”, etc.) freigeben. 
Die Funktion muß bei jeder Event-CPX implementiert sein. ACJXOSE ist als Klick auf “Ab¬ 
bruch” oder “Cancel” zu werten, WM_CLOSE als “OK” (Bemerkung: CPX-Module sollten 
so selten wie möglich Speicher reservieren). 

Deklaration in C: 

void cdecl <*cpx_close)(WORD flag); 

Eingabe-Parameter: 

flag: 0: ACJXOSE-Mitteilung 

sonst: WM_CLOSE-Mitteilung 
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Von XControl bereitgestellte Funktionen 


“ :---:---;-;-“i 

rshjfix (Objektbaum-Umwandlung) 


Wandelt einen Objektbaum auf Basis von 8x16 Pixel großen Zeichen - also pixelgenau und 
nicht auf Basis des aktuellen Systemzeichensatzes - um. Die CPX hat somit unter allen Auf¬ 
lösungen die gleiche Pixelgröße. Bei der Arbeit mit einem RCS sollte man daher ebenfalls 
einen Grafikmodus mit 8x16 Pixel großen Zeichen wählen. 

Die Koordinatenumwandlung darf natürlich nur ein einziges Mal stattfinden - XControl stellt 
dazu in der XCPB-Struktur das Flag “SkipRshFix” zur Verfügung. 


Deklaration in C: 

void cdecl (*rsh__fix) (WORD num_objs, WORD num_frstr, WORDnum_frirag, 
WORD num_tree, OBJECT *rs_object, TEDINFO *rs__tedinfo, 
char *rs_string[], ICONBLK *rs_iconblk, 

BITBLK *rs_bitblk, long *rs_frstr, long *rs_frimg, 
long *rs_trindex, struct foobar *rs_imdope); 

Eingabe-Parameter: 

analog zu den C-Resourcen, die vom Atari-RCS angelegt werden 


rshobfix (Objekt-Umwandlung) 


Entspricht der Funktion “rsrc_obfix()”, nur daß die CPX-spezifische Umrechnungsregel von 
Zeichen- in Pixelkoordinaten benutzt wird. 


Deklaration in C: 

void cdecl (*rsh obfix)(OBJECT *tree, WORD curob); 


Eingabe-Parameter: 

tree: Zeiger Objektbaum 

curob: zu konvertierendes Objekt 
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Popup (Popup-Menü) 


Diese Funktion ermöglicht die komplette Verwaltung eines Popup-Menüs. Bei zu vielen Ein¬ 
trägen (ab fünf) wird automatisch gescrollt. Die Abarbeitung des Popup blockiert alle anderen 
Aktionen. 



Deklaration in C: 

WORD cdecl (*Popup) (char *iteras[], WORD num_items, WORD default_item, 
WORD font size, GRECT *button, GRECT *world ); 


Eingabe-Parameter: 


items: Array mit Zeichenketten für die einzelnen Einträge. Jeder einzelne Eintrag muß 

die gleiche Länge haben sowie vome mindestens zwei und am Ende mindestens 
ein Leerzeichen aufweisen. 
num_items: Anzahl der Einträge 

defaultjtem: Default-Eintrag (Zählung beginnt bei 0) oder -1 

font_size: Zeichengröße; 8x16- oder 8x8-Font: Als Parameter sind die gleichen Werte wie 

in der TEDINFO-Struktur - also 3 (groß) bzw. 5 (klein) - zu verwenden. Laut 
Atari wird zur Zeit nur der große Zeichensatz verwendet, 
button: Rechteck des Buttons, zu dem das Popup-Menüs gehört 

world: Rechteck des Hintergrund-Objektbaums (in der Regel der Objektbaum der 


CPX) 


Ausgabe-Parameter: 
gewählter Eintrag (ab 0) oder -1 
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SIsize (SlidergrÖße) 

. . --■ - 1 


“Sl_size()” stellt die Größe des Sliders ein, damit die Relation der dargestellten Datenmenge 
zur vorhandenen gewahrt bleibt. 

Deklaration in C: 

void cdecl (*Sl_size)(OBJECT *tree, WORD base, WORD slider, 

WORD num_items, WORD visible, WORD direction, 
WORD min size); 


Eingabe-Parameter: 


tree: 

base: 

slider: 

numjtems: 

visible: 

direction: 

min_size: 


Zeiger auf Objektbaum 

Basisobjekt (Hintergrundobjekt für Slider) 

Slider; Objekt, welches innerhalb des Basisobjekts bewegt wird (Child des 
Basisobjekts) 

Anzahl der tatsächlich vorhandenen Elemente 

Anzahl der sichtbaren Elemente 

Richtung (VERTICAL (0) oder HORIZONTAL (1)) 

Minimalgröße des Sliders in Pixeln 
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Sl_x, Sl_y (Positionierung eines Sliders) 


Die beiden Funktionen positionieren den Slider innerhalb eines Basisobjekts in horizontaler 
bzw. vertikaler Richtung. 


Deklaration in C: 

void cdecl (*Sl_x)(OBJECT *tree, WORD base, WORD slider, 
WORD value,WORD nurn_min, WORD max, 
void (*foo)(void)); 

void cdecl (*Sl_y)(OBJECT *tree, WORD base, WORD slider, 
WORD value, WORD nurn_min, WORD max, 
void (*foo)(void)); 


Eingabe-Parameter: 

tree: Zeiger auf Objektbaum 
base: Basisobjekt 

slider: Slider (Child des Basisobjekts) 
value: neuer Wert, den der Slider repräsentieren soll 
min: Minimalwert, den value annehmen darf 
max: Maximalwert, den value annehmen darf 

foo: Adresse einer Funktion (oder NULL), die gleichzeitig mit der Slider-Neupositionierung 

aufgerufen wird; so lassen sich Sliderbewegungen ausnutzen, um auch die angezeigten 
Werte zu erneuern. 
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Sl_arrow (Sliderarrow) 


Sobald einer der zu dem Slider gehörigen Pfeile angeklickt wird, ist diese Funktion aufzurufen. 
Sie wird auch dazu benutzt, um einen Klick auf das Basisobjekt des Sliders auszuwerten. 


Deklaration in C: 

void cdecl (*Sl_arrow)(OBJECT *tree, WORD base, WORD slider, 

WORD obj,WORD inc, WORD min, WORD max, 
WORD *value, WORD direction, 
void (*foo)(void)); 


Eingabe-Parameter: 


tree: 

base: 

slider: 

obj: 

inc: 


min: 

max: 

value: 

direction: 

foo: 


Zeiger auf Objektbaum 
Basisobjekt 

Slider (Child des Basisobjekts) 

Pfeil, der angeklickt wurde 

Inkrementierung (Anzahl der Einheiten, die addiert oder subtrahiert werden 

sollen); sollte für angeklicktes Basisobjekt (seitenweises Blättern) und Arrow- 

button (zeilenweises Blättern) unterschiedlich sein 

Minimalwert, der angenommen werden kann 

Maximalwert, der angenommen werden kann 

Adressen für aktuellen Wert 

VERTICAL (0) oder HORIZONTAL (1) 

Adresse einer Funktion analog zu “Sl_x()” und “Sl_yO” 
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SI_dragx, Sldragy (Sliderdrag-Bewegung) 


Beim Draggen des Sliders wird selbiger angeklickt und bei festgehaltener Maustaste innerhalb 

eines Basisobjekts bewegt. Die beiden Funktionen verwalten diese Bewegung. 

Deklaration in C: 

void cdecl (*Sl_dragx)(OBJECT *tree, WORD base, WORD slider, 

WORD min,WORD max, WORD *value, 
void (*foo)(void)); 

void cdecl (*Sljdragy)(OBJECT *tree, WORD base, WORD slider, 

WORD min,WORD max, WORD *value, 
void (*foo)(void)); 


Eingabe-Parameter: 

tree: Zeiger auf Objektbaum 

base: Basisobjekt 

slider: Slider (Child des Basisobjekts) 

min: Minimalwert, der angenommen werden kann 

max: Maximalwert, der.angenommen werden kann 

value: Adresse für aktuellen Wert 

foo: Adresse einer Funktion analog zu “Sl_x()” und “Sl_yö” 
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Xformdo (Formular-Verwaltung) 


Die Formular-Verwaltung erfolgt analog zu der bekannten AES-Funktion “form_do()”, ist 
jedoch etwas komplexer. Sie übernimmt in geringem Umfang auch das Bearbeiten von AES- 
Mitteilungen. 


Deklaration in C: 

WORD cdecl (*Xfonn_do)(OBJECT *tree, WORD startob, WORD *puntrasg); 


Eingabe-Parameter: 

tree: Objektbaum (wie bei “form_do()”) 

startob: Start-Objekt (wie bei “form_do()”) 

puntmsg: Mitteilungs-Puffer (ähnlich “evnt_mesag()”/“evnt_multi()”) 


Ausgabe-Parameter: 

-1: puntmsg enthält eine Nachricht, die auszuwerten ist: 

WM_REDRAW (20): Die CPX muß solche Objekte selbst neuzeichnen, die nicht 
zum Objektbaum gehören. Die Rechteckliste ist über 
“GetFirstRectö” und “GetNextRectO” abzufragen. 

AC_CLOSE (41), 

WM_CLOSE (22): Die CPX wurde beendet. Reservierter Speicher ist sofort 

freizugeben. 

AC.CLOSE ist als “Abbruch” und WM_CLOSE als “OK” zu 
werten! 

CT_KEY (53): Eine spezielle Nachricht, die die Auswertung von Ta¬ 

stendrücken erlaubt, sofern diese keine Auswirkungen auf 
Editfelder haben können - also Funktionstasten, HELP und 
UNDO. puntmsgP] enthält Scancode (High-byte) und ASCII- 
Code (Lowbyte) der gedrückten Taste. 

sonst: Nummer des angeklickten Objekts (im oberen Bit die Kennzeichnung für einen Dop¬ 
pelklick) 
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GetFirstRect, GetNextRect (Rechteckliste) 


Die Rechteckliste, die zum Neuzeichnen von Fensterbereichen nach einer WMJREDRA W- 
Message nötig ist, wird mit den beiden Funktion. “GetFirstRectO” und “GetNextRectO” 
abgefragt. Den Objektbaum verwaltet jedoch XControl selbst! 


Deklaration in C: 

GRECT * cdecl (*GetFirstRect)(GRECT *prect); 
GRECT * cdecl (*GetNextRect)(void); 

Eingabe-Parameter: 

prect: Zu aktualisierender Bereich 

Ausgabe-Parameter: 

NULL: keine weiteren Ausschnitte vorhanden 

sonst: wiederherzustellender Ausschnitt 


Set_Evnt_Mask (Eventmaske setzen) 

Bei Event-CPX bestimmt “Set_Evnt_Mask()”, auf welche Events die CPX reagieren soll. 

Deklaration in C: 

void cdecl (*Set_Evnt_Mask)(WORD mask, MOBLK *ml, MOBLK *m2, 

long time); 


Eingabe-Parameter: 

mask: erlaubte Events (analog zu “evnt_multi()”) 

ml, m2: jeweils Mausrechteck und -richtung 

time: Zeit in Millisekunden für Timerevent 
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XGen_Alert (Alarmbox) 


Eine einfache Form einer Alarmbox bietet “XGen_Alert()”. Die Funktion bietet Alarmboxen 
jedoch nur für wenige Fehlermeldungen an, weitere Alarmboxen müssen selbst definiert 
werden. “form_alert()” bietet sich hier jedoch nicht an, da es die Alarmbox bezüglich der 
vollen Bildschirmfläche und nicht bezüglich des XControl-Fensters zentriert. 


Deklaration in C: 

WORD cdecl (*XGen Alert)(WORD id); 


Eingabe-Parameter: 

id: 0: SAVE.DEFAULTS (“Voreinstellungen sichern?”) 

1: MEM_ERR (“Fehler bei Speicheranforderung!”) 

2: FILE_ERR (“Fehler beim Schreiben/Lesen von Dateien!”) 
3: FILE_NOT_FOUND (“Datei nicht gefunden!”) 


Ausgabe-Parameter: 

0: “Abbruch” bzw. “Cancel” wurde angeldickt. 

sonst: “OK” wurde angeklickt (wenn eine Alarmbox nur einen Knopf hat, ist es der OK- 
Button!). 
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CPXSave (Defaults sichern) 


Defaulteinstellungen können mit “CPX_Save()” gesichert werden. Dies wird beispielsweise 
dann benötigt, wenn bestimmte Einstellungen beim Bootvorgang voreingestellt werden 
sollen. Um die Einstellungen zu speichern, sucht XControl eine CPX mit passendem Namen. 
Wird keine Datei mit passendem Namen gefunden, dann sucht XControl nach übereinstim¬ 
mender ID und Versionsnummer. Ist die CPX anhand der ID und der Versionsnummer 
gefunden, so wird die CPX aktiviert, ansonsten meldet XControl - wie auch im Falle einer 
schreibgeschützten Diskette — einen Fehler. 

XControl speichert die Einstellungen im DATA-Segment der CPX. Entwickler müssen selbst 
für ausreichend freien Speicherplatz im DATA-Segment sorgen. Dies geschieht über das 
Datenfeld SAVE_VARS in CPXSTART.S. 


Deklaration in C: 

WORD cdecl (*CPX_Save)(void *ptr, long num); 


Eingabe-Parameter: 

ptr; Adresse der zu speichernden Daten 

num: Anzahl Byte der in das DATA-Segment zu speichernden Daten 


Ausgabe-Parameter: 

0: Es ist ein Fehler aufgetreten, 

sonst: Alles in Ordnung. 
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GetJBuffer (Zwischenspeicher ermitteln) 


Einen Zeiger auf einen 64 Byte großen, residenten Speicherbereich liefert die Funktion 
“GetJBuffer”. Hier kann eine CPX die Inhalte von Write-Only-Registem sichern, sofern TOS 
keine Funktion zur Abfrage bietet (Beispiel: Fensterfarben). In diesem Zusammenhang sei 
noch einmal darauf hingewiesen, daß jeder andere Speicher einer CPX flüchtig ist! 

Deklaration in C: 

void cdecl (*Get Buffer) (void); 


Ausgabe-Parameter: 

Zeiger auf residenten Speicherbereich 


getcookie (Cookievariablen abfragen) 

“getcookie” prüft, ob ein bestimmter Cookie vorhanden ist und liefert gegebenenfalls deren 
Wert. 

Deklaration in C: 

WORD cdecl (*getcookie)(long cookie, long *p_value); 


Eingabe-Parameter: 

cookie: Cookievariable 

p_value: Adressen einer Variablen, die den Wert beinhalten soll, oder NULL, falls der Wert 
uninteressant ist 


Ausgabe-Parameter: 

0: Cookie nicht gefunden 

sonst: Cookie gefunden 
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Die Mausform kann gesichert (und wiederhergestellt) werden, womit der Mauszeiger 
temporär verändert werden kann. Dies ist beispielsweise dann nötig, wenn während einer Sli- 
derbewegung die “flache Hand” eingeschaltet wird. Es kann nicht davon ausgegangen wer¬ 
den, daß der Mauszeiger vorher eine bestimmte Form hatte! 


Deklaration in C: 

void cdecl (*MFsave) (WORD saveit, MFORM *mf) ; 


Eingabe-Parameter: 

saveit: 1: MFSAVE (Mausform sichern) 

0: MFRESTORE (Mausform wiederherstellen) 
mf: Speicherbereich zur Sicherung der Mausform 
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Kapitel 6: Richtlinien zur Benutzerführung 
und Programmierung 

Grundsätzliches zu grafischen Benutzeroberflächen 

Benutzeroberfläche 

(user surface, user Interface) Präsentation einer Software gegenüber dem Anwender durch 
Anzeigen von Arbeits- und Bedienungselementen auf dem Bildschirm und Unterstützung von 
Eingabehilfen wie Tastatur, Grafiktablett oder Maus. 


Benutzerfreundlichkeit 

Eigenschaft eines Computersystems und der dazugehörigen Software. Die Benutzerfreund¬ 
lichkeit der Hardware (z. B. Ein-/Ausgabegeräte wie Tastatur, Bildschirm, Drucker) hängt 
hauptsächlich von der ergonomischen Gestaltung und einer guten Dokumentation ab. Die Be¬ 
nutzerfreundlichkeit der Software wird gemessen an der Art und Qualität der Bedienerfüh¬ 
rung. 


Bedienerführung 

Bezeichnung für die Einrichtung einer Software zur Unterstützung des Anwenders, z. B. durch 
Auswahlmenüs, Hilfsprogramme, Sicherheitsabfragen oder auf dem Bildschirm angezeigte 
Bedienungshinweise. Die Bedienerführung soll auch Fehlbedienungen und damit zusammen¬ 
hängende Datenverluste verhindern. 

Am Anfang der Computer-Geschichte standen kommandoorientierte Benutzeroberflächen, 
die mit Benutzer freundlichkeit eigentlich nichts zu tun hatten. Der Bedienung des Computers 
ging ein kleines Studium der Befehle und Kommandos voraus. Beherrschte man diese dann 
soweit, daß Programme gestartet werden konnten, so schloß sich das nächste Studium an. 
Jedes Programm hatte seine eigene - teils recht konfuse - Oberfläche, jeder Programmierer 
programmierte einfach drauflos. Die Bedienerführung der meisten Programme war keines¬ 
wegs einheitlich und leicht erlernbar. 

Der Sinn einer einheitlichen - wenn auch nicht immer optimalen—Benutzeroberfläche wurde 
und wird von einigen noch immer nicht recht eingesehen. Wer sich allerdings schon intensiver 
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mit einer einheitlichen, grafischen Benutzeroberfläche wie GEM auseinandergesetzt hat, 
konnte schnell feststellen, daß derartige Oberflächen ihre Berechtigung haben und die 
Benutzeifreundlichkeit wesentlich erhöhen. Auch das WYSIWYG-Prinzip - What You See 
Is What You Get - entspringt den Ideen einer grafischen Oberfläche. 

Der Gestaltung und Realisierung einer durchdachten grafischen Oberfläche, die sich für alle 
Anwendungen einsetzen läßt, geht eine Untersuchung voraus, wie sich Menschen am 
Computer verhalten. 

Einer dieser gewichtigen Punkte ist das Muskelgedächtnis. Wer mit einer Schreibmaschine 
umgehen kann, wird alsbald feststellen, daß die Fertigkeit, Texte zu tippen, immer mehr 
zunimmt. Die Finger “erinnern” sich an die Lage der Tasten. Je größer dieses Erinnerungs¬ 
vermögen ist, um so schneller kommt der Text auf das Papier. 


Das Gesetz, welches dahinter steht, ist das sogenannte Gesetz von Fitt: 


t = i' log ( 
mit t; 
i: 
d: 

s: 

log: 


d / s + 0,5 ) 

Zeit, die man benötigt, um sich zu einem Objekt zu bewegen 
Proportionalitätskonstante (100 Millisekunden pro Bit) 
Abstand des Objekts vom gegenwärtigen Standort 
Größe des Objekts 
Logarithmus zur Basis 2 


Die Proportionalitätskonstante resultiert aus einer Art inneren Uhr im Menschen. In bezug auf 
grafische Benutzeroberflächen bedeutet dies: Wege zwischen zwei Objekten möglichst kurz 
halten, gleichartige Objekte immer an gleichen Plätzen unterbringen, denn wenn man schon 
weiß, wo ein anderes Objekt zu finden ist, dann ist der Weg dorthin auch kürzer (Vermeidung 
von Umwegen!). 

Auch die Größe der Objekte verringert die Zugriffszeit auf dasselbe Objekt. Daraus resultiert, 
daß z. B. Buttons in Dialogboxen recht groß ausfallen, wobei aber auf jeden Fall zu beachten 
ist, daß man dabei nicht das Maß der Dinge verliert. Zu groß ist nämlich nur unschön. Im Ge¬ 
genteil: Ein großflächiges Rechteck wird unter Umständen gar nicht mehr als Button erkannt! 

Das Muskelgedächtnis hilft, ein Objekt schnell zu finden, die Zugriffszeit kann dadurch kürzer 
werden. Die Zeit, die das Muskelgedächtnis selbst benötigt, läßt sich als das (Potenz-)Gesetz 
der Praktikabilität ausdrücken: 


t(n) = t(l) ■ n ■* 

mit t(n): Zeit für den n-ten Versuch 

a: approximative Konstante (ungefähr 0,4) 



Richtlinien zur Benutzerführung und Programmierung 


747 


Sind gleichartige Objekte immer an der gleichen Stelle, so benötigt man für den ersten Zugriff 
die Zeit t(l). Mit jedem neuen Versuch, die gleiche Funktion auszuüben, sinkt die Zugriffszeit. 
Bei nicht-standardisierten Oberflächen hingegen verbleibt man ewig bei der Zeit t( 1). Und das 
ist kein Gewinn! 

Das Muskelgedächtnis hilft, die rein manuelle Zugriffszeit zu vermindern. Die Reaktionszeit 
bedingt jedoch das Auge! Experimente haben gezeigt, daß die normale Wahmehmungszeit 
oder besser Unterscheidungszeit bei mindestens 50 bis 200 Millisekunden liegt. Bilder in 
zeitlichen Abständen von weniger als 50 Millisekunden werden nicht mehr bewußt, bei mehr 
als 200 Millisekunden jedoch garantiert als Einzelbilder wahrgenommen. Denken Sie hierbei 
an die niedrige Darstellungsfrequenz eines Fernsehers: Abstände zwischen zwei Bildern 
liegen etwa bei 40 Millisekunden, also dicht an der Grenze! 

Die Wahrnehmungsfähigkeit des Auges bedingt, daß auf dem Bildschirm zwei Ereignisse, die 
trennbar sein müssen, erst in einem bestimmten zeitlichen Abstand erfolgen können. Man muß 
wahmehmen, daß sich der Mauszeiger auf einem Objekt befindet! Diese zeitliche Verzöge¬ 
rung bei den Wahrnehmungen kann durch bestimmte Ereignisse verkürzt werden. Das Auf- 
flackem eines invertierten Bildes wird schneller bemerkt. Eine Dialogbox mit hoher Farbinten¬ 
sität (schwarz auf weiß) wirkt für den Menschen vor dem Computer wie ein visueller Schock. 
Daraus folgt eine erhebl ich schnellere Wahmehmung. Denken Sie an die Icons bei Alarmboxen 
oder die Invertierung der Menüeinträge bei Berührung mit dem Mauszeiger oder an die 
schwarz auf weiß darstellten Icons, wenn sie angewählt wurden! 

Der Mensch verfügt über ein Kurzzeitgedächtnis, das jedoch nur eine beschränkte Infor¬ 
mationsmenge verarbeiten kann. Die Anzahl der Informationen beschränkt sich meist auf die 
“magische” Zahl Sieben. Die Summe der wahrnehmbaren Informationen liegt etwa um zwei 
über bzw. unter diesem magischen Wert (nach Miller). Aus dieser Zahl folgt, wie ein Menü 
gestaltet sein muß: maximal sieben Drop-Down-Menüs (zuzüglich dem Informationsmenü 
mit den Accessories). In jedem Drop-Down-Menü sollten sich wenige Gruppen von jeweils 
maximal sieben Einträgen befinden. Zusätzlich zu dieser durch die Anzahl der auftretenden 
Wahlmöglichkeiten bedingten Gestaltungsform ist ein Menü, bei dem die einzelnen Untermenüs 
bei der Berührung der Menüzeile mit dem Mauszeiger herunterfallen (Drop-Down), einfacher 
zu bedienen und zu erkennen als ein Menü, bei dem erst mit der Maus auf einen Eintrag geklickt 
und somit das Untermenü (bei gedrückter Maustaste) heruntergezogen werden muß (Pull- 
Down). 

Auch Farben sollten im Userinterface - wenn überhaupt -nur sehr sparsam eingesetzt werden. 
Einmal daher, weil die Programme sowieso ohne Verlust der Bedienbarkeit auch auf 
monochromen Bildschirmen funktionieren müssen. Andererseits sind Farben nur bedingt zur 
Übermittlung zusätzlicher Informationen geeignet, da ein bedeutender Teil der Bevölkerung 
unter Farbenblindheit bzw. einer Farbsehschwäche leidet und die Erkennung und Bewertung 
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von Farben hochgradig subjektiv ist. Farben sollten also ausschließlich dann eingesetzt 
werden, wenn sie zur Klarheit der Darstellung beitragen! 

Der Faktor “denken” spielt somit auch eine große Rolle. Ein Mensch vor dem Computer sollte 
nicht dauernd nachdenken müssen! Bedienungselemente müssen intuitiv bedienbar sein! Die 
Überlegung, wie eine Funktion nun zu bedienen war oder wo eine bestimmte Einstellung 
vorgenommen werden kann, verbraucht kostbare Zeit. Daß diese Zeit nicht immer entfallen 
kann, dürfte klar sein. Eine Anwendung sollte aber den Menschen darin unterstützen, 
möglichst wenig Bedienungselemente erlernen zu müssen. Ein Ziel muß sich in maximal 
sieben Schritten (hier ist die magische Zahl wieder!) erreichen lassen. 

Nehmen wir ein Beispiel: Sie schreiben einen Brief und entdecken einen falschen Buchstaben. 
Was ist zu tun? Buchstaben finden, Hand zur Maus bewegen, Mauszeiger auf Buchstaben 
bewegen, einmal klicken, Hand zur Tastatur bewegen, Buchstaben löschen, neuen Buchsta¬ 
ben eingeben. Ein Benutzer muß aber nicht nur den Bewegungsablauf kennen, der hilft, einen 
Buchstaben zu löschen. Vielmehr muß dabei in Erinnerung bleiben, an welcher Stelle am 
Dokument gerade geschrieben wurde, was gerade geschrieben werden sollte, wo der fehler¬ 
hafte Buchstabe erblickt wurde und wie der neue Buchstabe aussieht. Je größer die Anzahl der 
zu merkenden Dinge wird, desto eher besteht die Gefahr, durcheinanderzugeraten. Außerdem 
dauert ein Vorgang um so länger, je mehr Dinge in Erinnerung behalten werden müssen und 
je mehr Auswahlmöglichkeiten bestehen! 

Denken Sie beim Entwurf einer GEM-Anwendung an die unterschiedlichsten Benutzer. Am 
besten ist es, während der Entwicklungsphase unterschiedlich erfahrene Tester heranzuziehen. 
Es hat sich schon immer als vorteilhaft erwiesen, absoluten Laien aber auch Experten ein Pro¬ 
gramm in die Hand zu geben! Ein Programm muß sich von einem Sekretär wie von einer Pro¬ 
fessorin problemlos bedienen lassen! 

Die Gestaltung der Benutzeroberfläche 

Einleitung 

GEM stellt eine Schnittstelle zwischen einer Applikation und dem Anwender. Eine Schnittstelle 
hat einen einheitlichen Aufbau, damit es zwischen den beiden Partnern nicht zu Verständnis¬ 
schwierigkeiten kommt. Stellen Sie sich mal vor, die RS232-Schnittstelle verhielte sich auf 
jedem Rechner anders! Ebenso muß diese “Software”-Schnittstelle auch auf unterschiedlicher 
Hardware gleich sein. Eine saubere GEM-Anwendung sieht auf DOS-Rechnem genauso aus 
wie auf einem Atari TT. Neben der Einhaltung “äußerer” Konventionen sind auch “innere” 
zu beachten. Damit ist gemeint, daß eine Anwendung nicht nur mit einem bestimmten Monitor 
oder einer bestimmten Speicherkonfiguration funktionstüchtig ist. Programme, die hardwarenah 
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geschrieben wurden, sollten zumindest darauf achten, daß sie mit anderen Konfigurationen 
nicht abstürzen und daß die “äußere” Schnittstelle eingehalten wird. 


Menüs 

Die Gestaltung des Menüs ist eine der wichtigsten Komponenten eines GEM-Programms, 
denn die Menüleiste sieht man zuerst. Man kann sagen, daß die Menüleiste die Visitenkarte 
des Programms ist. Auch wenn ein Menü (und das ganze Programm) den Konventionen ent¬ 
spricht, so muß das nicht heißen, daß es damit langweilig werden muß. Auch so gibt es genug 
Freiräume für pfiffige und durchdachte Funktionen, 

Das “Muskelgedächtnis” spielt eine große Rolle bei der Gestaltung des Menüs. Wer ein GEM- 
Programm verlassen will, der sucht ein Dateimenü und darin den untersten Eintrag. Eine 
Information zum Programm vermutet man in dem Menü, in dem auch die Accessories 
angewählt werden. 

Ein Menü besteht aus der Menüleiste mit diversen Titeleinträgen für die jeweiligen Drop- 
Down-Menüs (“Drop-Down” wie “herunterfallen” im Gegensatz zu “Pull-Down” wie “herun¬ 
terziehen”). Jedes einzelne Drop-Down-Menü enthält in jeder Zeile einen Eintrag. 

In der Menüzeile befinden sich immer die Einträge “Datei” und der Programmname - wie bei 
den PC-Versionen (“DESK” darf sich nur das Desktop nennen!). Der Eintrag mit dem Pro¬ 
grammnamen (in Großbuchstaben) steht bei Atari-GEM ganz links, bei PC-GEM rechts in der 
Menüleiste. Man weiß also immer sofort, zu welchem Programm die Menüleiste gehört (unter 
einem Multitasking-GEM sehr wichtig!). 

Abgesehen von diesem Titel ist das “Datei”-Menü ganz links zu finden. “Datei” und die 
anderen Titel sind immer mit einem Großbuchstaben am Anfang gehalten (Ausnahme: Abkür¬ 
zungen). Jeder Titel besteht aus nur einem Wort und besitzt als Abgrenzung zu den anderen 
Titeln je ein Leerzeichen rechts und links. 

Da es aber nicht nur ein Datei- und Informationsmenü gibt, haben sich weitere Standardtitel 
eingebürgert. Ein “Edit”- bzw. “Bearbeiten”-Menü befindet sich - sofern vorhanden - rechts 
vom “Datei”-Menü. Ein “Hilfe”-Menü ist ganz rechts einzuordnen und ein “Parameter”- oder 
“Optionen”-Menü links neben dem “Hilfe”-Menü. Somit sind schon insgesamt fünf Titel 
vorbelegt. Die restlichen Titel (maximal acht) können annähernd frei gesetzt werden. Auf 
verbreitete, gute Vorbilder sollte dabei nach Möglichkeit Rücksicht genommen werden. 

Gerade bei den Menütiteln machen sich viele Unsauberkeiten breit. Manch ein Menü hat schon 
mehr als zehn Titel, oder die Anzahl der Leerzeichen rechts und links von einem Titel weicht 
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stark von den Konventionen ab. Dabei verlängern unnötig viele viele Leerzeichen die Wege, 
die mit dem Mauszeiger zurückgelegt werden müssen. Auch die Schreibweise der Titel ist 
nicht immer schön (nur Großbuchstaben oder “Desk” anstelle des Programmnamens). 

Die Drop-Down-Menüs bestehen aus einzelnen Einträgen (jeweils einer pro Zeile), wobei 
ganz rechts ein Tastaturkürzel zu finden ist. Diesem Tastaturkürzel kann neben einem alpha¬ 
numerischen Zeichen (Buchstaben, Ziffern) für eine Taste, die stellvertretend für den Eintrag 
steht, ein besonderes Zeichen (links von dem Buchstaben) zugeordnet werden. Dieses Zeichen 
ist ein Pfeil nach oben (ASCII 1) für eine der Shift-Tasten, eine Raute (ASCII 7) für die 
Altemate-Taste oder ein “ A ” (ASCH 94) für die Control-Taste. 

Um die Funktion zu erreichen, die hinter dem Menüeintrag steht, ist dann die jeweilige Sonder¬ 
taste in Verbindung mit der angegebenen Taste zu drücken. 

Die Tastenkürzel werden mit mindestens einem Leerzeichen vom restlichen Eintrag abge¬ 
setzt. Der eigentliche Eintrag beginnt immer zwei Zeichen vom linken und eines vom rechten 
Rand entfernt, um Platz genug für ein Häkchen zu haben. Dabei ist es nicht relevant, ob dort 
überhaupt ein Häkchen plaziert werden soll. 

Das Häkchen stehtfür eine aktivierte Funktion. Solche Menüeinträge mit “Umschaltcharakter” 
sollten sparsam eingesetzt werden. Bei vielen Einstellungen ist es ratsam, diese in einer 
Dialogbox zusammenzufassen. 

Drei Punkte rechts vom Text eines Eintrags sind immer dann hinzuzufügen, wenn nach einem 
Klick auf den Eintrag oder nach dem Drücken der zugehörigen Tastenkombination ein Dialog 
folgt. Einträge, die nicht selektiert werden dürfen, werden vom Programm automatisch auf 
hell - DISABLED - gesetzt. Dies geschieht auch während des Programmablaufs. 

Es hat ja auch wenig Sinn, “sichern” anklicken zu dürfen, wenn nichts zu sichern ist. Sobald 
eine Wahl des Eintrags wieder sinnvoll ist, wird der Status DISABLED zurückgenommen. 

Eine letzte Form der Einträge sind Separatoren. Ein Separator ist eine durchgehende Linie 
(eine Reihe einfacher Bindestriche), die vom linken bis zum rechten Rand geht. Hier werden 
ausnahmsweise keine Leerzeichen am linken und rechten Rand freigelassen. Separatoren 
dienen zur Unterteilung von Einträgen in einem Drop-Down-Menü. Sie fassen mehrere 
Einträge optisch zu einer Funktionsgruppe zusammen. 

Jedes Drop-Down-Menü hat seine typischen Einträge. So hat das Menü mit dem Programm¬ 
namen den Info-Eintrag. 

Daneben findet man in diesem Menü die Einträge für die verschiedenen Accessories. 
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Das “Datei”-Menü beinhaltet als untersten Eintrag (“Ende”) immer die Möglichkeit, das 
Programm zu verlassen. Eine Sicherheitsabfrage vor dem Verlassen eines Programms ist nur 
dann sinnvoll, wenn irgendwelche Änderungen an einer Datei noch nicht gesichert wurden! 

Die anderen Einträge befassen sich tatsächlich mit Dateien und lauten von oben nach unten 
“neu anlegen”, “öffnen”, “schließen”, “sichern”, “sichern unter”, “abbrechen” und “an 
Ausgabe”. Hierbei bedeutet “neu anlegen”, daß ein Arbeitsbereich für eine neue Arbeit unter 
dem Namen ‘NAMENLOS ’ angelegt wird. Beim Abspeichem ist dann ein Name zu vergeben, 
da eine Datei ohne Namen logischerweise auf dem Massenspeicher nicht existieren kann. 
“Sichern” oder auch “abbrechen” sind nach Anwahl dieses Eintrags sinnigerweise gesperrt. 

Bei “Öffnen” wird eine bereits bestehende Datei Uber eine Dateiauswahlbox ausgesucht und 
geladen, bei “schließen” wird die aktuell bearbeitete Datei geschlossen, ohne gesichert zu 
werden. Jedoch sollte unbedingt eine Sicherheitsabfrage erfolgen, um Fehlbedienungen aus¬ 
zuschließen. 

Das Abspeichem einer Datei wird über “sichern” oder “sichern unter” ermöglicht, wobei bei 
der zweiten Variante über eine Dateiauswahlbox ein neuer Dateiname gewählt werden kann. 
“Sichern” kann nur dann gewählt werden, wenn das oberste Fenster ein nicht-namenloses 
Dokument enthält. Ist eine vorher namenlose Arbeit über “sichern unter” abgespeichert 
worden, dann ist sie fortan nicht mehr ohne Namen, und die Einträge “sichern” und “abbre¬ 
chen” können freigegeben werden. 

Die Option “sichern unter” läßt sich auch hervorragend dazu einsetzen, einen selektierten 
Block abzuspeichem. Ist ein Block gekennzeichnet, so fragt die Anwendung nach, ob der 
gesamte Text oder nur der Block gesichert werden soll. 

“Letzte Fassung” setzt alle seit dem Öffnen der Datei gemachten Änderungen wieder zurück, 
gegebenfalls durch einfaches Neuladen der Datei. Klickt man auf “an Ausgabe”, so startet das 
GEM-Ausgabeprogramm, um beispielsweise den Ausdruck einer Meta-Datei zu bewerk¬ 
stelligen. Allerdings kann auch die Ausgabe direkt erfolgen. 

Einträge wie “ausschneiden”, “kopieren”, “einfügen” oder “Undo” befinden sich im Bearbei¬ 
ten- bzw. Edit-Menü. 

Unter “Undo” versteht man eine Funktion, die die letzte Aktion wieder rückgängig macht, 
“ausschneiden” und “kopieren” (engl, “cut” und “copy”) bewirken, daß ein gekennzeichneter 
Block in einen internen Speicher (oder ins Clipboard; über Parameter einstellbar) kopiert wird, 
“ausschneiden” beinhaltet zusätzlich das Löschen des Blocks, “einfügen” bringt den gespei¬ 
cherten Block wieder zurück in den Arbeitsbereich. Die drei Grandfunktionen ermöglichen 
das Löschen eines Blocks (in den Puffer kopieren) und auch das Verschieben (ausschneiden 
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und an anderer Stelle wieder einfügen), womit zahlreiche Funktionen überflüssig werden 
können. Es bleibt den Programmierern überlassen, weitere sinnvolle Funktionen zu ergänzen. 

Das “Parameter”- oder “Optionen”-Menü enthält Einträge, die zu weiteren Funktionen der 
Applikation führen. Die Funktionen erlauben es jedem Anwender, die Applikation den eige¬ 
nen Bedürfnissen anzupassen und diese Einstellungen in einer Datei (mit der Namenserwei¬ 
terung “INF”) zu sichern. 

Eine Hilfe zu einer Applikation kann einerseits über die Taste “Help” und andererseits über 
das “Hilfe”-Menü abgerufen werden. Hier werden zumeist weitere Dialoge mit diversen 
Hilfstexten angezeigt. Die kleinen Alertboxen sollten nicht benutzt werden, da sie zu wenig 
Informationsmöglichkeiten bieten. Auch Einträge wie “ A = Control” dürfen nicht aufgeführt 
werden, da sie einerseits einen Eintrag unnötig belegen und andererseits irreführend sind: 
obwohl selektierbar, würde mit ihnen keine Funktion ausgelöst werden. 

Nun zu den Proportionen des Menüs. Wie schon eingangs erwähnt, sollten maximal acht Drop- 
Down-Menüs vorhanden sein. Die Titel überschreiten in der Regel eine Breite von etwa 12 
bis 16 Buchstaben nicht. In jedem Drop-Down-Menü finden sich höchstens lObis 12Einträge 
inklusive der Separatoren. Ein Eintrag ist (mit den zwei Leerzeichen zu Beginn und dem 
Tastenkürzel und einem Leerzeichen am Ende) maximal 20 bis 25 Zeichen breit. 
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Abb. 6.1: Vorschläge für vorbildliche Menüs 
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Dialoge 

Bei der Gestaltung der Dialogboxen ist auf innere und äußere Konsistenz zu achten. Man 
orientiert sich an vorbildlichen Dialogboxen anderer Programme (äußere Konsistenz) und 
achtet darauf, daß innerhalb einer Anwendung die Dialogboxen eine einheitliche Gestaltung 
haben (innere Konsistenz). Zur inneren Konsistenz gehört zudem noch, daß jede Aktion vor¬ 
hersehbar ist und nicht etwas völlig Unerwartetes passiert. 

Die Lage der Exit-Buttons ist durch die äußere Konsistenz bereits nahezu vorgegeben, da die 
Dateiauswahlbox die Exit-Buttons rechts unten und die Alertboxen die Buttons rechts (PC- 
GEM) oder unten (Atari-GEM) haben. Eine Plazierung am oberen oder linken Rand sollte also 
vermieden werden. Nach Möglichkeit sollten die Buttons in einer Reihe neben- oder 
übereinander angeordnet werden. 

Die Größen der Buttons folgen der einfachen Regel “nicht zu groß und nicht zu klein”: in der 
Höhe die eineinhalbfache Zeichenhöhe und die Breite des breitesten Buttöntexts in der Dialog¬ 
box nicht wesentlich überschreiten. Der breiteste Button ist so breit wie der Text, der in dem 
Button steht, zuzüglich einem Leerzeichen am rechten und linken Rand, also maximal Text- 
breite plus zwei (Ausnahme: ein “pathologischer” Fall wie “OK”). 

Als Standard-Exit-Buttons sind nahezu immer die Buttons “OK” und “Abbruch” zu finden,wobei 
“OK” eine Einstellung oder die Kenntnisnahme von einer Meldung bestätigt und “Abbruch” 
die in diesem Dialogschritt gemachten Änderungen ignoriert. Statt des “OK”-Buttons findet 
man auch vielfach Buttons, die mit einer bestimmten Aktion wie zum Beispiel “kopieren” 
gekennzeichnet sind. Damit die innere Konsistenz gewahrt bleibt, werden “OK” und “Ab¬ 
bruch” immer an den gleichen Stellen plaziert. Weitere Standard-Buttons existieren nicht. 
Aber auch unabhängig von der Lage diverser Objekte innerhalb einer Dialogbox existieren 
Regeln für die Anwendung eben dieser Objekte, damit die Bedienung einheitlich ist und sich 
jeder Anwender sofort zurechtfindet. 

GEM erlaubtes, Objekttypen wie Boxen (Rechtecke), Texte (veränderbar und nicht veränder¬ 
bar), Bilder (Images und Icons) sowie Mischformen daraus (Texte in Rechtecken: Boxtext, 
Button, Boxchar,...) zu verwenden. Sollte dies noch immer nicht reichen, so wird die Typen¬ 
vielfalt mit benutzerdefinierten Objekten ergänzt. Alle diese Typen können mit diversen 
Eigenschaften wie “wählbar” oder “Ausgang” und Status wie “abgehakt” oder “gesperrt” ver¬ 
sehen werden. 

Ausgang-Buttons (Flag EXIT) befinden sich immer dort, wo auch “OK” und “Abbruch” zu 
finden sind. Diese Buttons sind mit dem Flag EXIT zu versehen. Bei anderen sollte das EXIT- 
Flag nur dann gesetzt werden, wenn damit der Dialog nicht beendet wird. Das Flag DEFAULT 
(alternativ mit der Taste “Return” zu bedienen) darf nur dann gesetzt werden, wenn damit 
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keine irreversible Funktion - wie das Formatieren einer Diskette - aktiviert wird. Bei nicht 
umkehrbaren Aktionen sollten generell (Uber eine Option abschaltbare) Sicherheitsabfragen 
erscheinen, 

Gespent (Status DISABLED) sind alle Objekte, die bei dem betreffenden Dialogschritt nicht 
gewählt werden dürfen. Versteckt (Flag HIDETREE) werden die Objekte, die zu einem gewis¬ 
sen Zeitpunkt nicht nötig sind und nur störend wirken würden. Beispielsweise ist ein Hinweis 
auf eine Abbruchmöglichkeit eines Kopiervorgangs dann nicht nötig, wenn gar kein Kopier¬ 
vorgang im Gange ist. Der Status SELECTED signalisiert, daß eine bestimmte Wahl getroffen 
wurde oder eine Aktion aktiv ist. Daher darf dieser Status nicht an anderer Stelle (beispiels¬ 
weise für Dialogtitel) verwendet werden. 

Texte dienen auf der einen Seite der Information, und auf der anderen Seite ermöglichen sie 
eine Auswahl - z. B. bei den Dateinamen in der Dateiauswahlbox. Stehen diese Informations¬ 
texte als Beschreibung in einem Dialog wie “Größe:”, “Datum:”, dann stehen die Doppelpunk¬ 
te untereinander, und die Texte sind bezüglich dieser durch die Doppelpunkte vorgegebenen 
Linie rechtsbündig ausgerichtet. Bei linksbündigen Texten kann es zu zu großen Abständen 
kommen, wodurch der Zusammenhang verlorengeht. 

Bilder - Sie kennen den Spruch “ein Bild sagt mehr als 1000 Worte”? - werden als Hinweis¬ 
erklärung oder Abkürzung benutzt, müssen aber verständlich bleiben. Ihr Einsatz kann bei 
ungeschickter Wahl der Symbole leicht zu Verwirrung führen - wer verbindet schon einen 
Zauberhut mit einer Löschfunktion? 

Ein besonderes Kapitel sind Objekte mit den Flags SELECTABLE und RBUTTON (Radio¬ 
knopf). Diese Flags lassen sich prinzipiell für jedes Objekt benutzen. Schwierig wird es, wenn 
zu unterscheiden ist, ob ein Objekt nun wählbar ist oder nicht. Dies muß aus der Gestaltung 
der Dialogbox klar hervorgehen! 

Einfache, längere Texte oder Bilder werden nicht als Radioknöpfe installiert. Diese Möglich¬ 
keit bleibt einfachen Rechtecken, Zeichen in Rechtecken oder kurzen Texten wie “ja” oder 
“nein” Vorbehalten. Ein Rechteck ist ein gutes Signal dafür, daß ein wählbares Feld oder ein 
Radioknopf vorliegt, wobei hier bei der Gestaltung der Dialogbox darauf geachtet werden 
muß, daß derartige Objekte nicht mit Exit-Buttons verwechselt werden können. Der wohl 
beste Weg für Radioknöpfe ist, zusammengehörige in einem großen Rechteck unter- oder 
nebeneinander zusammenzufassen oder spezielle Felder (wie bei Formularen) vor Texten 
dafür vorzusehen. Einfach wählbare Objekte lassen sich prima darstellen, wenn vor einem 
Text ein kleines Rechteck zu sehen ist, welches “angekreuzf ’ werden kann. Allerdings ist dies 
nur über selbst definierte Objekte möglich. 

So vielfältig die Status sein mögen, sie sind sparsam - weniger ist mehr! - zu verwenden. 
Auch von der Verwendung verschiedener Füllmuster sollte man Abstand nehmen, denn 
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Abb. 6.2: Eine übersichtliche Dialogbox 

gerade die kontrastreichen Muster lenken Anwender nur von den eigentlichen Funktionen und 
Einstellungen ab. Neben der Möglichkeit, Objekte in einfacher Form zu gruppieren, gibt es 
eine weitere, um komplexe Objekte aufzubauen. 

Als Beispiel seien hier Listbox (wie in der GEM-Dateiauswahlbox) und Popup-Menüs (wie 
in XControl) genannt. 

Letztlich die Farben: Sie lockern die Dialogbox auf, lenken jedoch stark ab, wenn eine Dialog¬ 
box zu bunt gestaltet ist. Für Texte wird in der Regel schwarz gewählt, Warnungen ließen sich 
rot darstellen. Insgesamt sollten Farben sehr sparsam verwandt werden! 

Werkzeugleiste 

Reichen Menüs und Dialoge für die Zugriffsmöglichkeiten auf die Funktionen eines Pro¬ 
gramms nicht aus, so ergänzen zusätzliche Fenstermenüs oder Popup-Menüs die Anwendung. 
Die zusätzlichen Kontrollelemente finden in der Regel im rechten Randbereich eines Fensters 
ihren Platz. 
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Abb. 6.3: Ein Fenster mit Werkzeugleiste 


Es hat sich eingebürgert, diese Menüs mit Bildsymbolen zu gestalten. Je nach Anwendung 
verbergen sich hinter den Icons weitere Popup-Menüs (“RCS”) oder “Schalter” zwischen ver¬ 
schiedenen Betriebsmodi (“SciGraph”). 


Maus und Mauszeiger 

Sie werden sich sicherlich fragen, weshalb man sich mit so unscheinbaren GEM-Elementen 
wie dem Mauszeiger befassen kann. Aber auch der Mauszeiger hat je nach Form feste Bedeu¬ 
tungen. 

Ein Einfachklick dient der Auswahl bestimmter Elemente (Radioknöpfe, Icons) oder dem Zei¬ 
gen auf diese, ein Doppelklick leitet eine spezielle Funktion ein (Öffnen eines Fensters nach 
einem Doppelklick auf ein Icon). Nach einem Einfachklick kann in der Regel eine weitere 
Aktion ausgelöst werden, wie zum Beispiel das Ändern der Farbe eines Grafikobjekts. Prinzi- 
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piell ist neben dem Einfach- und Doppelklick auch ein Drei- oder Vierfachklick möglich. Da 
die Ausführung eines Drei- oder Vierfachklicks den meisten Anwendern erhebliche Schwie¬ 
rigkeiten bereiten dürfte, ist diese Form des Mausklicks wenn überhaupt nur optional zu 
verwenden. 

Aus der Einfachklickmöglichkeit ergibt sich ein weiteres Bedienungselement. Läßt man näm¬ 
lich die Maustaste nicht sofort los, sondern hält sie gedrückt, so können ausgewählte Objekte 
verschoben oder eine Gruppe von Objekten angewählt werden. 

Diese Möglichkeit wird beispielsweise vom Desktop ausgenutzt, um mehrere Dateien selek¬ 
tieren zu können oder Laufwerkssymbole zu verschieben. Aber auch Grafikprogramme nut¬ 
zen den Klick mit Festhalten, beispielsweise, um Linien zu ziehen. 

In Verbindung mit den Tasten “Altemate”, “Control” oder “Shift” ergeben sich weitere Mög¬ 
lichkeiten der Mausbenutzung, wobei diese Bedienungselemente nicht a priori klar sind. Üb¬ 
lich ist, daß in Verbindung mit einer Shift-Taste weitere Objekte (auch unter Verwendung der 
Rubberbox) ausgewählt werden können (“Erweitern der Auswahl”). Die Form bzw, Darstel¬ 
lungsart des Mauszeigers ist je nach Funktion, die gerade ausgeübt werden soll, unterschied¬ 
lich: 


Darstellungsart 

Funktion 

Pfeil: 

allgemeine Bedienung (Regelfall) 

Balken: 

Texteingabe 

Biene bzw. Sanduhr: 

der Rechner ist beschäftigt, z. B. mit Speichern einer Datei 

Zeigefinger: 

Auswahl oder Dimensionierung 

flache Hand: 

Verschieben von Objekten, Positionierung 

Fadenkreuz, dünn: 

Zeichnen oder Auswahl 

Fadenkreuz, dick: 

keine feste Bedeutung 

Fadenkreuz, Umriß: 

keine feste Bedeutung 

unsichtbar: 

bei Zeichenoperationen, wenn der Mauszeiger stört, oder bei 
Rasterkopie 

sichtbar: 

eigentlich immer, wenn er nicht gerade zum Zeichnen 
abgeschaltet ist 


Unabhängig von der Möglichkeit, den Mauszeiger an- und abschalten zu können, sollte der 
Mauszeiger immer sichtbar sein. 

Auch bei langwierigen Operationen wie dem Kopieren von Disketten bleibt der Mauszeiger 
- als Biene bzw. Sanduhr - sichtbar! 
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Tastaturbelegung 

Die Finger “gewöhnen” sich nur langsam an die Lage der einzelnen Tasten auf der Tastatur 
- wer häufig zwischen Rechnern mit deutscher und amerikanischer Tastaturbelegung wech¬ 
seln muß, kennt das Problem. Gleiches gilt natürlich für Befehlstasten-Kombinationen, mit 
denen Standardfunktionen aufgerufen werden. Daher ist eine Normierung zumindest der 
wichtigsten Shortcuts unbedingt nötig. Die aufgelisteten Tastenkombinationen sollen verdeut¬ 
lichen, was sich bisher eingebürgert hat und somit als Quasistandard anzusehen ist. 

Genormt laut Beschluß der Entwicklerkonferenz vom August 1989: 


Tastenbelegung 

Funktion 

Ctrl-C 

kopieren (“copy”) 

Ctrl-F 

suchen (“find”) 

Ctrl-O 

öffnen (“open”) 

Ctri-Q 

Programm beenden (“quit”) 

Ctrl-V 

einfügen (“paste”) 

Ctrl-X 

ausschneiden (“cut”) 

Shift-“Pfeil oben” 

eine Seite zuriickblättem 

Shift-“Pfeil unten” 

eine Seite vorwärtsblättern 

Shift-“Pfeil links” 

Einfügemarke zum Zeilenbeginn 

Shift-“Pfeil rechts” 

Einfügemarke zum Zeilenende 

Ctrl-“Pfeil links” 

um ein Wort zurück 

Ctrl-“Pfeil rechts” 

um ein Wort vorwärts 

Home 

Dokumentanfang 

Shift-Home (Clr) 

Dokumentende 


Weitere übliche Tastenkombinationen: 


Tastenbelegung 

Funktion 

Ctrl-A 

alles auswählen 

Ctrl-G 

nächste Fundstelle 

Ctrl-M 

Sichern unter... 

Ctrl-N 

Neues Dokument 

Ctrl-P 

Drucken 

Ctrl-S 

Sichern 

Ctrl-R 

Ersetzen 

Ctrl-U 

Oberstes Fenster schließen 
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Tastenbelegung 

Funktion 

Ctrl-W 

zum nächsten Fenster blättern 

Ctrl-Y 

aktuelle Zeile ausschneiden 

Ctrl-Z 

Shell starten 


Wer schon einmal an einer englischen Tastatur gesessen hat, der kennt die Probleme, die sich 
aus der Vertauschung der Tasten Y und Z ergeben. Aber nicht nur bei den üblichen Buch¬ 
staben-Tasten spielt die Gewohnheit eine große Rolle: Auch bei Tastenkombinationen für 
Befehle spielt die Gewöhnung eine sehr große Rolle. Um Problemen mit unterschiedlichen 
Scancodes aus dem Wege zu gehen, empfiehlt es sich, nach Möglichkeit immer den ASCI3- 
Code des Zeichens zu benutzen. Für Tastenkombinationen mit “Altemate” kann man die 
XBIOS-Funktion “Keytblö” zu Rate ziehen. Eine kleine Routine nach einer Vorlage von Ken 
Badertscher zur unabhängigen Auswertung der Tastatur: 

/* Bits zur Kennzeichnung der Shift-Status */ 


#define KsCAPS 0x10 
#define KsALT 0x08 
#define KsCONTROL 0x04 
#define KsSHIFT 0x03 
#define KsLSHIFT 0x02 
#define KsRSHIFT 0x01 


/* 

* Masken für die Status-Bits, die im oberen Byte des von MapKey 

* zurückgegebenen Words plaziert sind 
*/ 


#define KbSCAN 

0x8000 

fdefine KbNUM 

0x4000 

#define KbALT 

0x0800 

#define KbCONTROL 

0x0400 

#define KbSHIFT 

0x0300 

tdefine KbLSHIFT 

0x0200 

#define KbRSHIFT 

0x0100 

/* Scan-Codes für die 

Tasten, deren ASCII-Code 0 ist */ 


/* 

* ISO Taste (erscheint, wenn ein Nicht-US-Keyboard mit US TOS 

* benutzt wird) 

*/ 

fdefine KbISO 0x37 
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/* Funktionstasten */ 


#define KbFl 

0x3b 

tdefine KbF2 

0x3c 

tdefine KbF3 

0x3d 

#define KbF4 

0x3e 

#define KbF5 

0x3f 

tdefine KbF6 

0x40 

idefine KbF7 

0x41 

tdefine KbF8 

0x42 

tdefine KbF9 

0x43 

tdefine KbFlO 

0x44 

/* Shift-Funktionstasten */ 

tdefine KbFll 

0x54 

tdefine KbF12 

0x55 

tdefine KbF13 

0x56 

tdefine KbFl4 

0x57 

tdefine KbF15 

0x58 

tdefine KbF16 

0x59 

tdefine KbF17 

0x5a 

tdefine KbFl8 

0x5b 

tdefine KbFl9 

0x5c 

tdefine KbF20 

0x5d 

/* Cursor-Bereich */ 


tdefine KbUNDO 

0x61 

tdefine KbHELP 

0x62 

tdefine KbINSERT 

0x52 

tdefine KbHOME 

0x47 

tdefine KbUP 

0x48 

tdefine KbDOWN 

0x50 

tdefine KbLEFT 

0x4b 

tdefine KbRIGHT 

0x4 d 

/* Alternate-numerische 

Taste */ 

tdefine KbAltl 

0x78 

tdefine KbAlt2 

0x79 

tdefine KbAlt3 

0x7a 

tdefine KbAlt4 

0x7b 

tdefine KbAlt5 

0x7 c 

tdefine KbAlt6 

0x7 d 

tdefine KbAlt? 

0x7e 
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tdefine KbAlt8 0x7f 

#define KbAlt9 0x80 

#define KbAltO 0x81 

typedef struct 

{ 

char *unshift; 
char *shift; 
char *caps; 

} KEYTABLE; 

KEYTABLE *kt; 

/* Ändert eine VDI-Taste (Rückgabewert von evnt_keybd()) 
zu einem Word-großen, codierten Zeichen: 

Highbyte Lowbyte 

- ACLR sind Shift-Status-Bits 

SxxxACLR CHARCODE = ASCII (S = 0)- oder Scan (S = l)-Code 

Mit dieser Funktion wird das diffizile Problem der internatio¬ 
nalen Tastaturen und der Umwandlung der landerspezifischen VDI- 
Tasten in unabhängige ASCII- oder Scan-Codes gelöst.. */ 

WORD MapKey (WORD key) 

{ 

WORD keystate, scancode, ret; 

/* Ermittlung der Tastaturtabellen, falls noch nicht 
geschehen */ 
if (!kt) 

kt = (KEYTABLE *)Keytbl ((VOID*) -1L, (VOID*) -1L, 

(VOID*) -1L); 

/* Feststellung des Scan-Codes und der Shift-Status 

(ohne die Shift-Status von evnt__multi oder grafjnkstate) */ 
scancode = (key »8) & OxFF; 
keystate = (WORD) Kbshift (—1); 

/* Prüfung des ASCII-Codes mit der geeigneten Tabelle */ 

/* Anpassung der Alternate-numerischen Tasten */ 
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if ((keystate & KsALT) && (scancode >= 0x78) 

&& (scancode <= 0x83)) 
scancode -= 0x76; 
if (keystate & KsCAPS) 

{ 

ret = kt->caps[scancode]; 

} 

eise 

{ 

if (keystate & KsSHIFT) /* Shift-Funktionstasten haben 

korrespondierende Scan-Codes */ 
ret = kt->shift[((scancode >= KbFll) && 

(scancode <= KbF20))? scancode - 0x19;scancode]; 

eise 

ret = kt->unshift[scancode]; 

} 


/* Rückgabe der Scancodes, zu denen es keinen ASCII-Code gibt, 
und Kennzeichnung der numerischen Tastatur */ 
if (!ret) 

ret = scancode | KbSCAN; 

eise if ((scancode == 0x4a) || (scancode == 0x4e) || 

((scancode >= 0x63) && (scancode <= 0x72))) 
ret |= KbNUM; 

return (ret I (keystate « 8)); 

} 


Selektion 

Wie man Objekte auswählt, macht das Desktop bereits vor: einzelne Objekte durch einfaches 
Anklicken, mehrere Objekte durch Shift-Kliek oder die Rubberbox. Eine spezielle Methode 
zum Auswählen ist das “Echtzeit”-Selektieren. 

Viele Programme, wie “Wordplus”, “Edison” oder “Turbo C” verfolgen dieses Verfahren. 
Kernpunkt ist, daß der aktuell ausgewählte Block bereits während der Mausbewegung inver¬ 
tiert wird (um so besser, wenn beim Erreichen des Fensterrandes auch automatisch gescrollt 
wird). Weitere Varianten erlauben das wortweise Markieren (Markiervorgang mit einem Dop¬ 
pelklick beginnen) und vieles mehr. 
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Bei Programmen, die diese im “Inside Macintosh” beschriebene Methode konsequent nutzen, 
gibt es immer nur einen Block oder eine Einfügemarke - nie aber beides gleichzeitig. Das ist 
kein Fehler, sondern ist im Konzept dieses Mechanismus begründet: Alles dreht sich um die 
aktuelle “Selektion” (damit ist der gerade markierte Block gemeint). Der Cursor (besser: die 
Einfügemarke) ist nur ein Sonderfall eines Blocks (nämlich einer mit der Länge Null). 

Auch beim Einfügen gibt es keine Unterscheidung zwischen Blöcken und einzelnen Zeichen 
(ein Zeichen ist eben ein Block der Länge Eins). Der einzufügende Block wird immer anstelle 
des gerade selektierten Blocks eingesetzt. Anschließend erscheint die Einfügemarke (also der 
“leere” Block) rechts des eingefügten Blocks. Das gesamte Macintosh-Blockkonzept beruht 
somit auf dem Einfügen und Entfernen von Blöcken: Gute Ideen erkennt man daran, daß sie 
einfach sind! 

Einige “Blöcke”, die man einfügt, haben natürlich besondere Funktionen. “Backspace” und 
“Delete” löschen den selektierten Block. Falls nichts selektiert ist, wird vorher entweder das 
Zeichen rechts oder links der Einfügemarke selektiert. Ähnlich intuitiv sind auch andere 
Funktionen wie das Finden von Textstellen (der gefundene Text wird zum aktuell selektierten 
Block und kann damit direkt überschrieben werden) oder das Löschen von Zeilen (aktuelle 
Zeile als Block markieren und dann ausschneiden). Und in diesem Zusammenhang werden 
auch die einzelnen Menüpunkte des “Edit”~Menüs leicht verständlich. “Ausschneiden” ent¬ 
fernt den aktuellen Block und kopiert ihn in die “Zwischenablage”, einen internen Puffer. 
“Kopieren” kopiert den selektierten Block in die “Zwischenablage”, ohne ihn zu löschen. 
“Einfügen” fügt denmomentanen Inhalt der Zwischenablage in das Dokument ein. “Löschen” 
löscht den aktuellen Block, “Alles auswählen” selektiert alle Objekte im Dokument. “Undo” 
schließlich macht die letzte Blockoperation rückgängig. 

Die Zwischenablage enthält immer nur den zuletzt hineinkopierten Block. Viele Programme 
erlauben es, beim Ausschneiden und Kopieren durch Festhalten der Shift-Taste den Block an 
den Inhalt der Zwischenablage anzuhängen, statt ihn zu ersetzen. Ob die Zwischenablage nun 
als programmintemer Puffer oder direkt über das GEM-Klemmbrett (siehe Beschreibung der 
Scrap-Funktionen) verwirklicht wird, ist zunächst egal. Falls nicht sowieso das GEM- 
Klemmbrett (also der Weg über Dateien im Scrap-Verzeichnis) benutzt wird - die heutigen 
schnellen Festplatten machen das ja ohne weiteres möglich - sollte man diesen Weg zumin¬ 
dest als Option anbieten. “SciGraph” beispielsweise bietet für diese Umschaltung den Menü¬ 
punkt “Klemmbrett benutzen” an. 


Feedback 

Feedback bedeutet: dem Anwender Informationen über die ablaufenden Arbeitsschritte 
geben. Ein derartiges Feedback läßt sich auf vielerlei Art und Weise erreichen. Dazu gehört, 
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daß Menütitel während der gesamten Ausführung einer Funktion, die einem Eintrag in diesem 
Menü zuzuordnen ist, invers dargestellt bleiben. Auch die wachsenden und schrumpfenden 
Rechtecke vor bzw. nach einem Dialog stellen eine Methode des Feedback dar und sind beson¬ 
ders dann nützlich, wenn per Tastaturshortcut auf ein selektiertes Objekt zugegriffen wird. 

Die Form des Mauszeigers signalisiert, was gerade zu erledigen ist. Dauert die Ausführung 
einer Funktion länger an, so hat der Mauszeiger die Form einer Biene. Befindet sich der 
Mauszeiger über einem Texteingabefeld, so wird er als gesplitteter Balken dargestellt. 

Bei längeren Vorgängen wie dem Kopieren von Dateien oder dem Formatieren von Disketten 
signalisiert eine Dialogbox, welche Datei gerade kopiert wird oder wie weit der Formatier¬ 
vorgang fortgeschritten ist. Diese Anzeige ist nach Möglichkeit grafisch zu gestalten. 


Allgemeine Regeln 

Die Bedeutung und Anwendung wichtiger GEM-Komponenten wurde bereits angesprochen. 
Nicht nur der korrekte Einsatz der Komponenten, sondern auch das Zusammenspiel ist eine 
Herausforderung an den Programmierer. GEM wurde unter anderem deshalb geschaffen, um 
den Menschen, der an der Maschine sitzt, nicht von der eigentlichen Aufgabe abzulenken. Wer 
einen Brief schreibt, will nicht erst zahlreiche Kommandos erlernen. 

Auch die Kommandoebene, die ein Erlernen der Kommandos erfordert, soll einleuchtend 
gestaltet sein. Es ist eben einfacher, ein Dateisymbol auf ein Laufwerk zu ziehen, um eine 
Datei zu kopieren, als “COPY A:\DATEI.XYZ B: \ ORDNERN” einzugeben. 

GEM bietet die Möglichkeit, mit Bildern in Form von Icons die Arbeit zu erleichtern. Zudem 
ermöglichen die vielseitigen Ausgabefunktionen, das WYSIWYG-Prinzip (What You See Is 
What You Get) einzuhalten. Bei einer Textverarbeitung lassen sich z. B. Buchstaben, die auf 
dem Papier fett dargestellt werden, auch schon auf dem Bildschirm in fetter Schrift darstellen. 
GEM-Programme müssen immer so geartet sein, daß einem Anwender sofortklar ist, was etwa 
nach einem Klick auf einen Menüpunkt geschieht. 

Auch irreversible Eingriffe dürfen erst gar nicht entstehen oder benötigen zumindest eine 
Sicherheitsabfrage. 

Jede Komponente des GEM (Menüs, Dialoge, Fenster) hat seine feste Bedeutung. Programme 
lassen sich leichter bedienen, wenn es bei der Gestaltung der Oberfläche nicht zu Widersprü¬ 
chen kommt. Die korrekte Ausnutzung dieser Komponenten gehört zu jedem GEM-Pro- 
gramm. Selbstgestrickte Menüs, Dialoge und Fenster, die auf den ersten Blick schön oder 
“modern” erscheinen mögen, erschweren den Menschen vor der Maschine Computer nur die 
Arbeit und schrecken auf Dauer ab. 
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Programmtechnisches 


Einleitung 

Um es vorwegzunehmen: In diesem Kapitel soll kein vollständiges GEM-Programm mit 
Menü-, Dialog- und Fensterverwaltung entwickelt werden. Ein derartiges Beispielprogramm 
würde zu lang und könnte nicht allgemein genug gehalten werden. Das Hauptaugenmerk liegt 
vielmehr auf einigen Anregungen und Tips, die bei der Programmierung unter GEM Beach¬ 
tung finden sollten. 


Ein Rahmenprogramm 

Programmierung unter GEM setzt die Kenntnis der Funktionen und Strukturen voraus, 
Feinheiten wie die Parameter der einzelnen Funktionen sind jedoch nicht unbedingt nötig. Nur 
wer die Funktionen kennt und weiß, wie und wann sie eingesetzt werden, kann sichere GEM- 
Programme schreiben. Bevor Sie also zur Programmierung schreiten, lesen Sie die Kapitel mit 
den AES-Funktionen einmal - zumindest diagonal - und informieren Sie sich, was das VDI 
alles zu bieten hat. Schenken Sie beim VDI den Auskunftsfunktionen besonderes Augenmerk! 

Die Basis für alle GEM-Programme ist die An- und Abmeldung beim AES. Hierzu finden die 

Funktionen “appl Jnit()” und “appl.exit()” Verwendung. Die folgenden Programme in C und 

Modula-2 zeigen, wie der Minimalrahmen für ein Programm auszusehen hat: 

1. C-Programm: 

finclude <aes.h> 
tinclude <portab.h> 

WORD apl__id; 

void main (void) 

{ 

if ((apl_id = appl_init()) >= 0) 

{ 

/* hier kommt das eigentliche Programm... */ 
appl_exit() ; 

} 

} 
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2 . Modula-2-Programm: 

MODULE Programm; 

FROM AES IMPORT Appllnit, ApplExit; 

VAR Aplld : INTEGER; 

BEGIN 

Aplld := Appllnit (); 

IF Aplld >= 0 
THEN 

(* hier kommt das eigentliche Programm... *) 

ApplExit{) 

END 

END Programm. 

Diesen Minimalrahmen ergänzt bei einem Accessory ein Aufruf der Funktion “menu_register() M 
(für den Eintrag im ersten Drop-Down-Menü). In diesem Zusammenhang sei darauf verwie¬ 
sen, daß man mit keiner GEM-Funktion abfragen kann, ob eine ausführbare Datei als Accesso¬ 
ry öder Programm gestartet wurde. Funktionen wie “AccessoryO” bei Megamax Modula-2 
oder Variablen wie “_app” bei Turbo C gehören nicht zum GEM, aber es ist von Atari doku¬ 
mentiert, wie man solche Informationen ermittelt (siehe AES-Einleitung). 

Da Accessories GEM-typisch ereignisorientiert sind, erzwingt dies eine Verwendung von 
“evntjmesagO” oder “evnt_multi()”. Der Aufruf der Funktion “appl_exit()” entfällt, da 
Accessories unter keinen Umständen verlassen werden dürfen. Daher endet der Programm¬ 
ablauf im Fehlerfall in einer Endlosschleife, in der “evnt_mesag()” aufgerufen wird. 

Der Rahmen nimmt somit folgende Gestalt an: 

1. C-Prograinm: 

finclude <aes.h> 

#include <portab.h> 

char acc_name[] = " Accessory..."; /* Immer zwei Leerzeichen am 

Anfang! */ 


WORD apl id, menu id; 
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void main (void) 

{ 

WORD msg_buf fer[8]; 

if {(apl_id = appl_init{)) >= 0) 

{ 

if ((menu_id = menu__register (apl_id, accjname) >= 0) 

{ 

for (;;) /* Endlosschleife */ 

{ 

evnt_mesag (msg_buffer); 
switch (msg__buffer [0]) 

{ 

case AC_OPEN: 

if (msg_bufferf4] menu_id) 

{ 

/* Accessory wurde geöffnet... */ 

} 

break; 

case AC_CLOSE: 

if (msg_buffer[3] == menu_id) 

{ 

/* Accessory wurde geschlossen...*/ 

} 

break; 


} 

} 

} 

for (;;) evnt_mesag (msg_buffer); 

} 

2. Modula-2-Programm: 

MODULE Accessory; 

FRCM AES IMPORT Appllnit, MenuRegister, ErrntTimer, EvntMesag, 
KAcOpen, KAcClose; 

FROM Strings IMPORT Assign, String; 

CONST AccName = " Accessory..."; 

VAR Aplld, 
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MenuID : INTEGER; 

AccNameGlobal : String; 

MsgBuffer : ARRAY [0..7] OF INTEGER; 


BEGIN 

Aplld ;= ApplInitO; 

IF Aplld >= 0 
THEN 

Assign(AccName, AccNameGlobal); 

Menuld := MenuRegister(Aplld, AccNameGlobal); 

IF Menuld >== 0 
THEN 

WHILE TRÜE 
DO 

EvntMesag(MsgBuffer); 

CASE MsgBuffer[0] OF 
KAcOpen : 

IF MsgBuffer[4] = Menuld 
THEN 

(* das Accessory wurde angewählt... *) 

END | 

KAcClose : 

IF MsgBuffer[3] = Menuld 
THEN 

(* das Accessory wurde geschlossen... *) 

END 

END 

END 

END 

END; 

WHILE TRUE 
DO 

EvntMesag(MsgBuffer) 

END 

END Accessory. 

Fortan werden in erster Linie nur noch C-Beispiele benutzt, da die Ableitung von Modula-2- 
oder Pascal-Programmen klar sein dürfte. 

Die Namensbildung wird an anderer Stelle angesprochen, eine Kurzbeschreibung der C- 
Syntax befindet sich im Anhang. 
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Im Hinblick auf die Benutzung der VDI-Funktionen — sei es für Grafikausgabe in Fenstern, 
sei es für Objekte vom Typ G_USERDEF - ist das Öffnen einer virtuellen VDI-Workstation 
wichtig. Die Anmeldung erfolgt, indem das Handle der physikalischen Workstation via 
“grafJiandleO” abgefragt, ein Array mit passenden Werten gefüllt und die Funktion 
“v_opnvwk()” aufgerufen wird. Eine Fehlerabfrage geschieht durch Überprüfung des neuen 
Handles, das im Fehlerfall den Wert Null hat. 

Hier das Öffnen einer virtuellen Workstation auf einem Bildschirm, mit allen Grafiktypen und 
Rasterkoordinaten: 

vjhandle = grafjhandle (&gr_hwchar, &gr_hhchar, &gr_hwbox, 

&gr_hhbox); 

for (i = 0; i < 10; work_in[i++] = 1); 
work_in[10] = 2; 

v_opnvwk (work_in, &v_handle, work_out); 
if (vjhandle != 0) 

{ 

} 

Geschlossen wird diese virtuelle Workstation mit: 
v_clsvwk (v_handle )■ 

Nach dem Anmelden beim AES und dem Öffnen der virtuellen Workstation für die 
Grafikausgaben (falls nötig), steht nun der Programmierung nichts mehr im Wege. Als 
nächstes soll die Frage nach dem eigentlichen Programmablauf gestellt werden. 


Programmsteuerung über Ereignisse 

Im Gegensatz zu der mehr traditionellen Programmierung mit Warte- und Abfrageschleife, 
Ganzseitenmenüs und vollständiger Kontrolle desBildschirms und der anderen Ausgabegeräte 
durch das Programm wendet man sich bei der Programmierung unter GEM einer Orientierung 
auf Ereignisse zu. Diese Art der Programmierung findet sich auch bei den anderen, modernen 
Sy stemen wie etwa dem Presentation Manager unter OS/2 oder dem X-Window-System unter 
Unix. 

Ein ereignisorientiertes Programm schlummert so lange, bis es angestoßen wird. Ein solcher 
Anstoß - ein Ereignis - erfolgt je nach den Wünschen der Programmierer. GEM-Programme 
können auf Ereignisse unterschiedlichster Art reagieren: 
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- Tastatur-Ereignisse 
Mausknopf-Ereignisse 

- Maus-Ereignisse 

- Mitteilungs-Ereignisse 

- Zeit-Ereignisse 

Die einzelnen Ereignisse werden je nach ihrer Verwendung getrennt oder gesammelt 
abgefragt. Ein Zeit-Ereignis etwa beilängeren Operationen wird mit“evnt_timer()’”regelmäßig 
abgerufen, um anderen Applikationen etwas Zeit zu geben. Ein Accessory kann sich auf das 
Warten auf eine Nachricht beschränken, statt mit einem “evnt_multi()” auch noch (unnötige) 
Zeit-Ereignisse zu empfangen. 

Sobald die Programme komplexer gestaltet sind, kommt nur noch der Aufruf von “evnt_multi()’ ’ 
in Frage, denn hier muß ein Programm auf Ereignisse unterschiedlichster Art reagieren. Da 
wird mit der Maus auf ein Objekt geklickt (Mausknopf-Ereignis), ein Menüeintrag gewählt 
(Mitteilungs-Ereignis), ein Zeichen über Tastatur eingegeben (Tastatur-Ereignis) oder auch 
ein Fenster verschoben (Mitteilungs-Ereignis). Die möglichen Ereignisse sind in der AES- 
Einleitung dokumentiert. 

Um den prinzipiellen Aufbau einer Ereignisabfrage zu verstehen, ist es wichtig, den Unter¬ 
schied zu der traditionellen Programmierung zu verstehen. Beachten Sie dabei aber unbedingt, 
daß ein Programm erst auf ein Ereignis reagiert und nicht etwa in einer Schleife fortlaufend 
die Tastatur äbfragt, ob eine Taste gedrückt wurde! 

vorher: nachher: 


LOOP 

BusyRead(c); 
CASE c OF 

Space : EXIT| 

END 

END 


LOOP 

EvntKeybd(c) ; 
CASE c OF 

Space : EXITI 

END 

END 


Der wesentliche Unterschied der kurzen Modula-2-Routinen zwischen “vorher” und “nach¬ 
her” besteht darin, daß die Schleife bei “vorher” ununterbrochen durchlaufen wird, bei 
“nachher” jedoch pro gedrückte Taste nur einmal! Auch ist nur bei dem Aufruf von 
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“evnt_keybd()” ein Weiterarbeiten anderer, parallel laufender GEM-Applikationen möglich. 
Der Unterschied der beiden Tastaturabfragen mag auf den ersten Blick nicht offensichtlich 
sein, doch stellen Sie sich einmal vor, es ist auch noch in regelmäßigen Zeitabständen eine be¬ 
stimmte Funktion aufzurufen. Im ersten Fall müßte dann neben einer eventuell gedrückten Ta¬ 
ste auch noch die Uhrzeit abgefragt werden, im zweiten ist es aber nur erforderlich, “evnt_mul- 
ti()” anstelle von “evntjteybd()” zu verwenden. 

Hier ein kleines Beispiel zur Ereignisabfrage: 

for (;;) /* Endlosschleife */ 

1 

evnt = evntjnulti (MUJKEYB |MU_BUTTON|MU_M11MÜ_M2 |MU_MESAG I 
MUJTMER, 

evjnbclicks, ev_mbmask, evjnbstate, 
evjmmlflags, evjnmlx, evjnmly, evjnmlwidth, 
evjnmlheight, 

ev_mm2£lags, evjnm2x, ev_mm2y, evjnm2width, 
evjnm2height, 
evjnmgpbuff, 

evjntlocount, ev_mthicount, 

evjnmox, evjnmoy, evjnmobutton, evjnmokstate, 

evjnkreturn, 

evjnbreturn); 

if (evnt & MU_KEYBD) 

hdle_keybd (evjnkreturn); /* gedrückte Taste */ 

if (evnt & MU_BDTTON) 

hdle_button (evjnmox, evjnmoy, /* Position des 

Mauszeigers */ 

evjnmobutton, /* Status der Maustasten */ 

evjnmokstate, /* Status der Umschalttasten */ 

evjnbreturn); /* Anzahl der Mausklicks */ 

if (evnt & MU_M1) 

hdle_ml (evjnmox, evjnmoy, 
evjnmobutton, 
evjnmokstate) ; 

if (evnt & MU_M2) 

hdle__m2 (evjmmox, evjnmoy, /* Position des Mauszeigers*/ 


/* Position des Mauszeigers*/ 
/* Status der Maustasten */ 

/* Status der Sondertasten */ 



772 


ATARI Profibuch 


evjnmobutton, 
ev_mmokstate) ; 

if (evnt & MU_MESAG) 

hdle_mesag (ev_mmgpbuf); /* Adresse des Messagepuffers */ 

if (evnt & MU_TIMER) 
hdlejtimer (); 

} 

Da ein “evnt„multi()”-Aufruf nicht notwendigerweise nur genau ein Ereignis registriert, ist 
eine Benutzung einer Exklusiv-Auswahl wie mit 

switch (evnt) 

{ 

case .. : 

break; 
case .. : 
break; 

} 

nicht möglich! Bei einer Abfrage, welches Mitteilungs-Ereignis (MU_MESAG) aufgetreten 
ist, kann jedoch eine derartige Abfrage wieder erfolgen, da “evnt_multi()” nur maximal eine 
Mitteilung abgibt. Auf die einzelnen Ereignisse wird sinnvollerweise in gesonderten Funktio¬ 
nen reagiert, da so auch eine logische Aufteilung der Ereignisse im Programmlisting erreicht 
werden kann. Die Position des Mauszeigers und den Status der Sonder- und Maustasten wird 
von “evnt_multi()” übrigens immer zurückgegeben. Daher können diese Werte auch an alle 
Funktionen weitergereicht werden. 


/* Status der Maustasten */ 

/* Status der Sondertasten */ 


Fensterverwaltung 

Im Rahmen der Fensterverwaltung wollen wir an die oben besprochene Steuerung des 
Programms über Ereignisse anknüpfen. 

Für die Fensterverwaltung ist die in dem Beispiel erwähnte Routine “hdle_mesag()” von 
Interesse. Ihr wird die Adresse des Messagepuffers übergeben, der - im Falle eines Mittei¬ 
lungs-Ereignisses - die relevante Information enthält. 

Die Funktion “hdlw_mesag()” könnte folgenden Aufbau haben: 
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void hdlejmesag (WORD *ev_mmgpbuf) 

{ 

switch (ev__rnmgpbuf [0]) 

{ 

case AC_OPEN: 

/* Accessory wurde angewählt... */ 

/* Dies könnte das Öffnen eines Fensters bedingen. */ 
break; 

case AC_CLOSE: 

/* Accessory wurde geschlossen... */ 

/* Dies könnte das Schließen eines Fensters bedingen. */ 
break; 

case MN_SELECTED: 

/* Menüverwaltung... */ 

/* Dies könnte das Öffnen eines Fensters bedingen. */ 
break; 

/* ...und hier die Fensterverwaltung! */ 

/* falls Redraw-Meldung... */ 

case WM_RBDRAW: /* ID und Koordinaten übergeben */ 
wind_redraw (ev_mmgpbuf[3] r ev_mmgpbuf[ 4 ], 
ev_iwngpbu f [ 5 ], e v_mmgpbu f [ 6 ], 
ev_irmgpbuf [ 7 ]) ; 

break; 

/* falls Fenster aktiviert wurde... */ 
case WM__TOPPED: 

wind_topped (ev_mmgpbuf[3]); /* ID des Fensters */ 
break; 

/* falls Fenster geschlossen werden soll... V 
case WM_CLOSED: 

wind_closed (ev_mmgpbuf[3]); /* ID des Fensters */ 
break; 
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/* falls Fenster auf volle Größe gebracht werden soll */ 
case WM_FULLED: 

wind_fulled (evjnmgpbuf[3]); /* ID des Fensters */ 
break; 

/* falls einer der Pfeile angeklickt wurde... */ 
case WM_ARROWED: 

wind_arrowed (evjnmgpbuf[3], /* ID des Fensters */ 

ev_mmgpbuf [4] ); /* Art der Veränderung */ 
break; 

/* falls der horizontale Slider bewegt wurde... */ 
case WM_HSLID; 

wind_hslid (ev_ramgpbuf[3], /* ID des Fensters */ 

ev_mmgpbuf[4]) ; /* Position in Promille */ 
break; 

/* falls der vertikale Slider bewegt wurde... */ 
case WM_VSLID; 

wind_vslid (evjnmgpbuf[3], /* ID des Fensters */ 

ev_mmgpbuf[4]); /* Position in Promille */ 
break; 

/* falls die Größe des Fensters verändert wurde... */ 
case WM_SIZED: 

wind_sized (ev_mmgpbuf[3], /* ID des Fensters */ 

ev_mmgpbuf[4], /* x-Koordinate des Fensters */ 

evjnmgpbuf[5], /* y-Koordinate des Fensters */ 

evjnmgpbuf[6], /* neue Breite */ 

evjnmgpbuf [7])-; /* neue Höhe */ 
break; 

/* falls das Fenster bewegt wurde... */ 
case WM_MOVED: 

windjnoved (evjnmgpbuf[3], /* ID des Fensters */ 
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ev__inmgpbuf [ 4 ], 
evjnmgpbuf [5], 
evjanmgpbuf [6], 
ev_inmgpbuf [7]) ; 
break; 


/* 

neue 

x-Koordinate 

*/ 

/* 

neue 

y-Koordinate 

*/ 

/* 

Breite */ 


/* 

Höhe 

*/ 



1 


Die in diesem Beispiel aufgeführten wind-Funktionen sind wiederum durch die Programmie¬ 
rer zu deklarieren und beinhalten Aufrufe der AES-Fensterfunktionen. Den jeweiligen Fen¬ 
steraktionen können beispielsweise folgende AES-Funktionen zugeordnet werden: 

- beim Anlegen eines Fensters 

(legt die Fensterstruktur an, dies beinhaltet kein Öffnen des Fensters!) 


wind_create (): 
wind_calc (): 

beim Öffnen eines Fensters 

wind_open (): 
wind_set (WF_NAME,...): 
wind_set (WFJNFO,...): 
wind_set (WF_CURRXYWH,...): 
wind_set (WF_HSLIDE, 
wind_set (WF_VSLIDE,...): 
wind_set (WF_HSLSIZE,...): 
wind_set (WFJVSLSIZE,...): 

bei Ausgaben in ein Fenster 

wind_get (WF_WORKXYWH, 
wind_get (WFJHSLIDE,...): 
wind_get (WF_VSLIDE,...): 
wind_get (WF_FIRSTXYWH,...): 
wind_get (WF_NEXTXYWH, 
wimLget (WF_HSLSIZE,...): 
wind_get (WF_VSLSIZE,...): 
wind_set (WF_TOP,...): 
wind_update (BEG_UPDATE): 
wind_update (END_UPDATE): 


legt maximale Größe fest und liefert ID 
Größe berechnen 


öffnet das Fenster, setzt die Anfangsmaße 
setzt Fenstemamen 
setzt Infozeile 
setzt Fenstergröße 

setzt Position des horizontalen Sliders 
setzt Position des vertikalen Sliders 
setzt Größe des horizontalen Sliders 
setzt Größe des vertikalen Sliders 


Größe des Arbeitsbereichs 
Position des horizontalen Sliders 
Position des vertikalen Sliders 
erstes Rechteck der Rechteckliste 
nächstes Rechteck der Rechteckliste 
Größe des horizontalen Sliders 
Größe des vertikalen Sliders 
Fenster wird zum aktuellen 
Beginn einer Ausgabe/Emeuerung 
Ende einer Ausgabe/Emeuerung 
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bei einer Größenveränderung 

windlet (WF_CURRXYWH,...): 
wind_get (WF_PREVXYWH, ...): 
wind_get (WFFULLXYWH,...): 
windlet (WF_CURRXYWH, ...): 
wind_set (WF_HSLIDE,...): 
wind_set (WF_VSLIDE, ...): 
wind_set (WF_HSLSIZE,...): 
wind_set (WF_VSLSIZE,...): 

Verschieben eines Fensters 

wind_set (WF_CURRXYWH,...): 

Schließen eines Fensters 


aktuelle Größe 
bisherige Größe 
maximale Größe 
setzt Fenstergröße 

setzt Position des horizontalen Sliders 
setzt Position des vertikalen Sliders 
setzt Größe des horizontalen Sliders 
setzt Größe des vertikalen Sliders 


setzt Fensterkoordinaten 


wind_close (): schließt das Fenster 

Löschen eines Fensters (entfernt die Fensterstruktur aus dem Speicher!) 
wind_delete (): gibt die ID wieder frei 


Dialogverwaltung 

Zum Aufruf eines Dialogs sind verschiedene Schritte nötig. Zum einen gehören dazu 
Elemente des Feedbacks - die größer bzw, kleiner werdenden Rechtecke - und zum anderen 
die programmtechnisch erforderlichen Elemente. 

Die Verwaltung eines Dialogs teilt sich grundsätzlich in drei Teile auf: 

1. Vorbereitung 

2. Durchführung 

3. Nachbereitung 

Zur Vorbereitung gehört, daß kein anderes Programm weiter Ausgaben tätigt, die Mauskontrolle 
bei der Applikation liegt, die zu der Dialogbox gehört, und der Hintergrund reserviert wird. 
Die Durchführung beinhaltet den Aufruf der eigentlichen Verwaltungsroutine. Zuletzt die 
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Nachbereitung, die den Hintergrund wieder freigibt, die Kontrolle der Maus abgibt und 
anderen Applikationen die Ausgabe wieder erlaubt. Somit entsteht folgende Minimalfunktion: 

WORD do_dialog (OBJECT *dial) 

{ 

GRECT size; 

WORD rc; 

/* Vorbereitung */ 

wind_update (BEG__UPDATE); 
wind_update (BEG_MCTRL); 

form_center (dial, &size.g_x, &size.g_y, &size.g_w, 

&size.g_h); 

form_dial (FMD_START, size.g_x, size.g_y, size.g_w, size.g__h, 
size.g_x, size.g_y, size.g_w, size.g_h); 
objc_draw (dial, ROOT, MAX_DEPTH, size.g_x, size.g_y, 
size.g_w,size.g_h); 

/* Durchführung */ 

rc = formjdo (dial, ROOT) & 0x7FFF; 

/* Nachbereitung */ 

form_dial (FMD_FINISH, size.g_x, size.g_y, size.g___w, size.g_h, 
size.g_x, size.g_y, size.g_w, size.g_h); 
wind_update (END_MCTRL); 
wind_update (END_UPDATE); 

dial[rc],ob_state &= (~SELECTED); /* Knopf deselektieren */ 
return rc; 

} 

Die Funktion “do_dialog()” liefert die Nummer des Buttons zurück, mit dem der Dialog 
beendet wurde. Zu den Vorbereitungen gehört meistens das Setzen von Radioknöpfen, die 
Initialisierung der Editfelder und vieles andere. Der Nachbereitung ist somit die Auswertung 
veränderter Objekte und Editfelder zuzuordnen. 

Eine Abwandlung des Durchführungsteils erlaubt etwas komplexere Verarbeitungen. Hier 
läßt sich zum einen der Doppelklick auswerten (das oberste Bit bei dem von “form_do()” 
zurückgegebenen Wert) und zum anderen ein “Spezial”-Objekt installieren. “form_do()” 
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kann so lange in einer Schleife wiederholt werden, bis ein bestimmter Button angeklickt wor¬ 
den ist. Bei Auswahl eines anderen Elements lassen sich Slider und sonstige interessante Dinge 
installieren. Der Durchführungsteil hätte dann die Form: 

for (;;) 

{ 

rc = form_do (dial, ROOT ); 
doppelklick = rc & 0x8000; 
rc &= 0x7FFF; 

if ((rc == OK) [| (rc = ABBRUCH)) 
break; 

/* weitere, spezielle Auswertungen... */ 

} 

Abfragen z. B. auf den SELECTED-Status oder auf den Inhalt eines Editfeldes erfolgen direkt 
über die Objekts truktur. 

Frei definierte Objekttypen 

Ein komplettes Listing! Das kleine Programm demonstriert die Verwendung des Objekttyps 
G_USERDEF. Statt des “normalen” Select-Status wird ein Objekt mit einem Kreuzchen 
versehen. Ursprünglich handelte es sich bei dem betreffenden Objekt um eines des Typs 





Bitte Mahlen Sie: 

n fiusMahl 


Bitte Hählen Sie: 

SEI fiusMahl 



1 ÖR | 


1 ÖK | 




■ 



Dialoghox ohne GJÜSERDEF Dialogbox mit G_USERDEF 


Abh. 6.4: Dialogbox mit USERDEF-Objekt 
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G_BOX, das jedoch lediglich dazu benutzt wurde, die Größe des selbst definierten Objekts 
festzulegen. Das Programm erkennt, daß ein Typ G_USERDEF zu setzen ist, an dem vom 
GEM ignorierten oberen Byte des Typs (der in unserem Falle auf 0x01 gesetzt wurde). 

/* C-Programm, das ein Objekt vom Typ GJJSERDEF benutzt. */ 

/* Includes für GEM */ 

#include <aes.h> 

#include <vdi.h> 
tinclude <portab.h> 

/* Resourcedatei-Indizes */ 
ttinclude "demo.h" 

WORD apl_id, 

v_handle; 

OBJECT *dial; 

USERBLK user; 

/* Zeichenketten */ 

char no_resource[]="[3][|Resourcedatei|fehlt leider!][ OK ]", 
rsrc_name t] ="DEMO.RSC"; 

/* Prototypen */ 

WORD cdecl selbutton (PARMBLK *parmblock); 
void instal (OBJECT *dial, WORD obj); 

void tree_walk (OBJECT *dial, WORD Start, void (*callrout) 

(OBJECT *dial, WORD obj)); 
void do_dialog (OBJECT *dial); 
void main (void); 

/* Routine, die neuen Selectbutton ausgibt */ 

WORD cdecl selbutton (PARMBLK *parrriblock) 

{ 

WORD xy[8], xy_cl±p[4]; 

/* Clipping festlegen */ 
xy_clip[0) =■-- parmblock->pb__xc; 
xy__clip[l] = parmblock->pb_yc; 

xy_clip[2] = parmblock”>pb_xc + parmblock->pb_wc-l; 
xy_clip[3] = parmblock">pb_yc + parmblock->pb_hc-l; 
vs_clip (v_handle, 1, xy_clip); 


/* Application-ID */ 

/* VDI-Handle */ 

/* Zeiger auf Objektbaum */ 

/* USERBLK für G_USERDEF-Ob j ekt */ 
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/* Rechteck mit Rahmen ausgeben */ 
xyfO] = panriblock->pb_x+l; 
xy[l] = parrriblock->pb_y+l; 

xy[2] = parmblock->pb_x+pamnblock->pb_w-2; 
xy[3] = parmblock->pb_y+parmblock->pb_h-2; 
vsf_interior (v_handle, FIS_HOLLOW); 
v_bar (v_handle, xy); 

/* Kreuz als Kennzeichen für SELECTED ausgeben */ 
if (parmblock->pb_currstate & SELECTED) 

{ 

xy[6] = xy[0]; 

xy [5] = xy[1]; 

xy[4] = xy[2]; 

xy[7] = xy[3]; 

v_pline (v_handle, 2, xy); 

vjpline (vjiandle, 2, &xy[4]); 

} 

/* Clipping wieder aus */ 
vs_clip(v_handle, 0, xy_clip); 

return (parmbloek->pb_currstate & -SELECTED); 


/* installiert GJUSERDEF-Objekte */ 
void instal (OBJECT *dial, WORD obj) 

{ 

switch ( (dial [obj] .ob__type & OxFFOO) » 8) 

{ 

case 0x01 : 

dial[obj]. ob_type = GJJSERDEF; 
dial[obj].ob_spec.userblk = &user; 
user. ub__code = selbutton; 

} 

} 

/* wandert durch den ganzen Objektbaum ab (exklusiv) Start */ 
void tree_walk (OBJECT *dial, WORD Start, 

void (*callrout)(OBJECT *dial, WORD obj)) 
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{ 

WORD i; 

for (i = dial[start].ob_head; /* Kopf der Objektfolge */ 

(i != start) £& (i != -1); /* letztes zeigt auf Parent */ 
i = dialfi].ob_next) /* nächstes Objekt */ 

{ 

<*callrout)(dial, i); 
tree_walk (dial, i, callrout); 

) 

) 

/* do_dialog: siehe oben */ 

/* HauptProgramm */ 
void main (void) 

{ 

WORD i; 

WORD work_in[12], work_out[57], void__word; 

/* Application anraelden */ 
apl_id = appl_init (); 

if (apl_id >= 0) 

{ 

grafjnouse (HOURGLASS, OL) ; 

/* Resourcedatei laden */ 
if (rsrc_load(rsrc_name)) 

{ 

/* Adresse ermitteln */ 

rsrc_gaddr (R_TREE, DEMODIAL, &dial); 

/* VDI-Workstation anmelden */ 
v_handle = graf_handle (&void_word, &void_word, 
&void_word, &void_word); 
for (i =0; i < 10; work_in[i++] = 1); 
work_in[10] = 2; 

v_opnw;k (work_in, &v_handle, work_out); 
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/* GJJSERDEF setzen */ 

tree walk {dial, ROOT, instal); 

/* Mauszeiger als Pfeil */ 
graf_mouse (ARROW, OL); 

/* Dialog durchführen */ 
do_dialog (dial); 

/* VDI-Workstation schliepen */ 
v_clsvwk (v__handle) ; 

} 

eise /* Fehlermeldung */ 

form_alert (1, no__resource) ; 

appl_exit (); 

i 

} 

Hardwareunabhängigkeit 

GEM-Programme unabhängig von der Hardware zu schreiben ist nicht schwer. Die Grund¬ 
regeln lassen sich schnell auf einen einfachen Nenner bringen: 

Aufrufe tieferer Betriebssystemschichten unterlassen und keine unsicheren Annahmen über 
irgendwelche Gegebenheiten machen. 

Befehle und Bibliotheken der diversen Programmiersprachen (wie C) bieten einen großen 
Befehlsreichtum, womit Betriebssystemaufrufe in aller Regel unterbleiben können. 

Wird jedoch einmal eine spezielle Funktion benötigt, so deklariert man diese in einem eigenen 
Modul. Bei einer Portierung des Programms auf ein anderes System ist dann nur dieser eine 
Modul zu erneuern, die restlichen Moduln bleiben unangetastet. 

Um die Portabilität der verschiedenen C-Compiler untereinander zu erhöhen (manch ein Com¬ 
piler hat “int” als 16-Bit-Wert deklariert, ein anderer als 32-Bit-Wert), findet eine Datei “por- 
tab.h” Verwendung, wie sie hier in aller Kürze aufgeführt ist. 

(Die Datei "portab.h” von Digital Research bzw. Atari, wie sie z. B. bei Laser C mitgeliefert 
wird, enthält noch weitere Definitionen.) 
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/* PORTAB.H 

Include-Datei mit portablen Typendefinitionen für C. */ 

tifndef_PORTAB 

#define PORTAB 


tdefine 

BYTE 

signed char 

/* 

Byte (8 bits) mit Vorzeichen */ 

idefine 

UBYTE 

unsigned char 

/* 

Byte ohne Vorzeichen */ 

fdefine 


BOOLEAN int 

/* 

2 Werte: true/false */ 

#define WORD 

signed int 

/* 

Word (16 bits) mit Vorzeichen */ 

#define 

UWORD 

unsigned int 

/* 

Word ohne Vorzeichen */ 

fdefine 

LONG 

signed long 

/* 

Long (32 bits) mit Vorzeichen */ 

#define 

ULONG 

unsigned long 

/* 

Long ohne Vorzeichen */ 


#endif PORTAB 


Namensgebung von Betriebssystemfunktionen 

Wer mit mehr als einem Entwicklungssystem arbeitet und hier und da mal GEM-Programme 
von einem System auf das andere portieren muß, kennt das Problem, daß die Namen der GEM- 
Routinen nicht einheitlich sind. 

Bei C-Entwicklungssystemen ist es dabei noch recht einfach, denn die C-Namen der Funktio¬ 
nen und Konstanten sowie deren Aufbau sind von Digital Research vorgegeben. 

Bei Pascal-Entwicklungssystemen läßt sich eine Namensübertragung sehr leicht realisieren, 
denn die C-Namen könnenübertragen werden. Schwieriger erscheint jedoch die Namensgebung 
auf Modula-2-Systemen, denn zum einen ist die Schreibweise der Bezeichner anders (Groß- 
und Kleinbuchstaben, in der Regel keine Unterstriche, längere Namen), und zum anderen 
existiert kein bindender Standard für GEM/Modula-2-Namen, Als einfachster Weg der Na¬ 
mensbildung auf Grundlage der C-Nomenklatur bietet sich folgender von R. Schneider (Digi¬ 
tal Research) vorgeschlagene an: 

- alle Funktionsnamen (und Silben) beginnen mit großen Buchstaben und werden pro Sil¬ 

be mit kleinen Buchstaben fortgesetzt 


alle Unterstriche fallen weg. 
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Silben beziehen sich hierbei nicht auf sprachliche Silben, sondern auf die durch Unterstriche 
getrennten Bestandteile des C-Funktionsnamens. Somit ergeben sich beispielsweise die 
Namen 

- VRbox aus v .rbox 

- VFormAdv aus v_form adv 

- ShelRdef aus sheljrdef 

Konstanten entstehen nach dem gleichen Prinzip, jedoch kann den Namen ein Buchstabe - 
beispielsweise K - vorangestellt werden. Beispiel: 

- KGBoxtext aus G_BOXTEXT 
KShadowed aus SHADOWED 

Der Sinn dieser Namenswahl ist, daß auch ein Modula-2-Programmierer sofort auch die C- 
Literatur und dieses Buch verwenden kann, ohne jedesmal nachdenken zu müssen, wie der 
Modula-2-Bezeichner denn nun heißen könnte. An die etwas kryptische Schreibweise ge¬ 
wöhnt man sich recht schnell. 



Teil II 



Die Hardware des ST 
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Überblick über das System 

Bei den Atari-Computern der ST-Serie handelt es sich, wie schon bei den 8-Bit-Modellen der 
XL- und XE-Serie, um sogenannte Tastaturcomputer. 

Was andeutet, daß sich fast alle zum Betrieb benötigten Hardwarekomponenten zusammen 
mit der Tastatur in einem Gehäuse befinden. Ein solcher Tastaturcomputer ist bereits nach 
Anschluß der Stromversorgung und eines Sichtgerätes (Monitor) betriebsfähig. Sinnvolles 
Arbeiten ist jedoch erst mit Anschluß eines Massenspeichers (Floppy-Disk/Harddisk) mög¬ 
lich, weshalb bei den Modellen 520ST(FM)/1040ST(FM) bereits ein Floppy-Disk-Laufwerk 
mit einer Speicherkapazität von 720 KByte ins Gehäuse eingebaut wird. 

Die Geräte der MEGA ST-Serie fallen schon nicht mehr in diese Kategorie, da sie eine abge¬ 
setzte Tastatur besitzen. Die Intelligenz befindet sich einschließlich Stromversorgung in 
einem separaten Gehäuse, welches auch eine 720 KByte-Floppy beinhaltet und als Monitor¬ 
untersatz benutzt werden kann. 

Im Prinzip stellen sich jedoch die Computer der ST-Serie als ein System mit den Grund¬ 
komponenten Zentraleinheit, Grafiksystem, Musik- und Tonsystem und verschiedenen 
peripheren Untersystemen dar. Die Zentraleinheit besteht aus: 

- einem mit 8 MHz getakteten MC68000 Mikroprozessor 

- 192 KByte Festwertspeicher (ROM), durch einsteckbares Cartridge auf 320 KByte 
erweiterbar 

- 512 KByte Arbeitsspeicher (RAM) bei 260ST/520ST(FM) bzw. 1 MByte bei 520ST+ 
und 1040 ST(FM) (1,2 oder 4 MByte bei der MEGA ST-Serie). 

Das Grafiksystem in Stich Worten: 

- 32 KByte Bildschirmspeicher (beliebig im Arbeitsspeicher gelegen) 

- folgende Anzeigemodi sind möglich: 

320 x 200 Bildpunkte in 16 aus 512 möglichen Farben 
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640 x 200 Bildpunkte in vier aus 512 möglichen Farben 
640 x 400 Bildpunkte in S/W mit Monochrom-Monitor 

- Anschluß eines hochauflösenden Monochrom- oder eines Farbmonitors mit RGB-Ein- 
gang (beim 520ST(F)M/1040ST(F)M ist der Anschluß eines Fernsehers durch eingebau¬ 
ten HF-Modulator möglich). 

Das Musik- und Tonsystem enthält einen Soundchip mit drei programmierbaren Tonkanälen 
und einem Rauschgenerator. Die Hüllkurve ist programmierbar. 

Die peripheren Untersysteme im ST bestehen aus: 

- Tastatur-, Maus- und Joystick-Interface mit eigenem Mikroprozessor und über eine 
serielle Schnittstelle mit dem Hauptsystem verbunden 

- Parallel-Schnittstelle (in der Regel als Druckerinterface nach Centronics-Standard 
genutzt) 

serielle Schnittstelle (RS232) für Modem oder seriellen Drucker 

- Floppy -Disk-Interface für zwei Laufwerke bis je 720KByte (formatierter) Speicherkapa¬ 
zität 

- ATARI Computer Sy tem Interface (ACSI) mit DMA-Unterstützung zum Anschluß von 
schnellen Peripheriegeräten wie Harddisk, CD-ROM, Laserdrucker usw. 

- MIDI-Interface für Anschluß an digital steuerbare Musi kin strumente. 

Immer mehr Grips in immer weniger Chips 

Im ST befinden sich neben Standardbausteinen wie der 68000er-CPU, WD1772-Floppy- 
Disk-Controller,AY-3-8910-oder YM2149-Soundchip,68901-Multifunktionsbaustein, 6850- 
ACIAs (Bausteine für asynchrone, serielle Datenübertragung), RAMs und ROMs noch 
vier sogenannte Custom-Chips (beim STE wurde die Anzahl auf drei Custom-Chips redu¬ 
ziert, da GLUE und MMU zur GSTMCU zusammengefaßt wurden). Diese speziell von Atari 
für die ST-Computer entwickelten Chips enthalten eine Vielzahl von Funktionsgruppen, die 
für das einwandfreie Funktionieren des Systems erforderlich sind. Ihnen ist es zu einem großen 
Teil auch zu verdanken, daß ein Computer dieser Leistungfähigkeit zu einem so niedrigen 
Preis zu haben ist. 

Der SHIFTER sorgt dafür, daß Sie ein klares Bild von Ihrem ST erhalten. Er setzt nämlich die 
Information des Hauptspeicherbereichs, der für den Bildschirmspeicher reserviert ist, in ein 
Videosignal für den Monitor um. 
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Ahb. 0.1: Die einzelnen Komponenten eines ST 

Dazu verfügt er zwar über einen 16 Bit-Datenbusanschluß, der Adreßzähler für die entspre¬ 
chende darzustellende Bildschirmspeicher Adresse befindet sich jedoch in der MMU und wird 
dort verwaltet. Über entsprechende Registerauswahl- und Steuerleitungen lädt die MMU 
unter Mithilfe des GLUE (Steuersignalerzeugung) die SHIFTER-Register mit den Werten aus 
dem Bildschirmspeicher und für die Farbpalette. Mit dem 32 MHz-Mastertakt wird die 
Bildinformation dann als Color- oder Monochromsignal ausgegeben. 

Der BLITTER-Chip ist in den MEGA STs/STEs eingebaut und realisiert die Line-A-Funktion 
“Bit-Block-Transfer” mit Hardware-Unterstützung. Mit seiner Hilfe lassen sich ohne Umweg 
über die CPU blitzschnell große Datenbereiche im Bitraster manipulieren. 

Der BLITTER darf dazu ebenfalls wie die DMA-Einheit auf den Hauptspeicher direkt 
zugreifen. Zugriffe müssen jedoch mit der CPU und der DMA-Einheit abgestimmt werden, 
wobei der DMA-Betrieb des BLUTERs niedrigste Priorität besitzt. Im Gegensatz zum SHIF- 
TER ist der BLITTER ein eigener Co-Prozessor-Chip, der über einen vollwertigen Adreß- und 
Datenbus verfügt. Außerdem besitzt er alle nötigen Steueranschlüsse für die Steuerung des 
Daten- und Adreßbusses als eigenständige Einheit in einem 68000er-Prozessorsystem. 

Die DMA-Einheit hilft den Peripheriegeräten wie Floppy-Controller und den am ACSI-Bus 
angeschlossenen schnellen Peripheriegeräten wie Harddisk, CD-ROM und evtl. Laserdrucker 
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Abb. 0.2: Das Blockschaltbild des ST 





























Einführung 


791 


beim Datenaustausch. Sie kann dabei, genau wie die CPU direkt auf den Hauptspeicher 
zugreifen (deshalb DMA = Direct Memory Access) und die erforderlichen Daten für die Peri¬ 
pheriegeräte dort abholen oder deponieren. 

Die CPU hat mit dem Datentransfer also nicht mehr viel zu tun und könnte sich anderen 
Aufgaben widmen (tut sie aber nicht!). Dem DMA -Chip ist es ähnlich gegangen wie dem 
SHIFTER. Die entsprechenden Adreßzähler für die Abwicklung von DMA-Operationen 
befinden sich in der MMU. Lediglich ein 16 Bit-Anschluß zum Datenbus ist vorhanden, über 
den der DMA-Chip den DMA-Transfer abwickelt. Die Steuerung des Adreßbusses übernimmt 
der GLUE in Zusammenarbeit mit der MMU! 

Die Memory Management Unit (MMU) besorgt die Umsetzung der von der CPU ausgehenden 
Adreßinformation in einen gemultiplexten Adreßbus für die dynamischen RAMs. Außerdem 
werden von ihr die Refresh-Signale für die RAMs zur Verfügung gestellt, die dafür sorgen, 
daß die Speicherzellen in den RAM-Chips nicht plötzlich an “Gedächtnisschwund” leiden und 
ihren Informationsinhalt verlieren. Die MMU ist dazu vollständig an den Adreßbus angebun¬ 
den mit den zugehörigen Handshake-Leitungen für den Memory-Zugriff, 

Auf den Datenbus greift die MMU direkt nur zur Hälfte (D0..D7) zu. Diese Hälfte wird für 
das Laden der in diesem Chip integrierten Register wie für Memory-Configuration, die Video- 
Base- und Video-Counter-Register sowie die DMA-Base-Register verwendet. 

Der GLUE übernimmt die Decodierung der Adreßbereiche für RAM, Betriebssystem- und 
Cartridge-ROM und die peripheren Chips wie Soundchip, ACIAs und 68901. Weiterhin wer¬ 
den die für die CPU erforderlichen Steuer- und Quittungssignale fiirlnterrupts, Zugriffsberech¬ 
tigung auf geschützte Speicherbereiche usw. vom GLUE erzeugt. 

Der GLUE-Chip hat dazu einen vollwertigen Adreßbus-Anschluß und Zugriff auf alle CPU- 
Steuersignale. Dafür ist jedoch sein Datenbus-Anschluß entsprechend mager ausgefallen 
(gerade mal DO und Dl sind angebunden - also genausoviel wie der GLUE braucht, um das 
interne Sync-Mode-Register zu bedienen!). 

Wenn also bei den weiteren Erläuterungen von dem Video-Controller oder der DMA-Einheit 
die Rede ist, sind damit alle Register und Logikkomponenten gemeint, die für die angespro¬ 
chene Funktionseinheit erforderlich sind, egal in welchem Custom-Chip sie zu finden sind. 
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Kapitel 1: Die Zentraleinheit 

Die Zentraleinheit der Atari ST Computer besteht aus dem Mikroprozessor, dem Hauptspeicher 
und der DMA-Einheit. 


Der Mikroprozessor 

Das Herz des ATARI ST ist eine MC68000-CPU, die mit einer Frequenz von 8 MHz getaktet 
wird. Hierbei handelt es sich um eine 32-Bit-CPU, die intern eine Verarbeitung von Daten mit 
32 Bit Breite vomimmt. Der Datentransfer von und zur CPU erfolgt jedoch über einen 16 Bit 
breiten Datenbus (Daher auch die Bezeichnung ”ST” = Sixteen Thirtytwo= 16 Bit ext. 
Datenbus/32 Bit int. Datenbus). 


Es können also gleichzeitig zwei Bytes (ein Datenwort) übertragen werden, wobei aber auch 
Einzelbyte-Zugriffe möglich sind. Ein Befehl, um z. B. ein Datenwort aus einer Speicherstelle 
in eines der CPU-Register zu laden, benötigt im ST vier Taktzyklen, Bei einer Taktfrequenz 
von 8 MHz dauert das Ganze also nur 0,5 Mikrosekunden! 


Die CPU besitzt acht Daten- und neun Adreßregister mit je 32 Bit Breite, wobei zwei der neun 
Adreßregister Stapelzeiger (Stackpointer) darstellen. Zwei Stapelzeiger deshalb, weil die 
CPU zwei Betriebsarten kennt, den Supervisor-Modus und den User-Modus. Je nach Betriebs¬ 
art “sieht” das laufende Programm den Supervisor- oder den User-Stapelzeiger, 


Im Supervisor-oder System-Modus istvomProgrammher der Zugriff auf alle Speicherbereiche 
und das gesamte Statusregister der CPU möglich. 


Im User- oder Benutzer-Modus kann nicht auf Daten des Supervisorspeicherbereichs zuge¬ 
griffen werden, so daß sich eine erhöhte Sicherheit gegen versehentliches Manipulieren von 
für das Betriebssystem “lebenswichtigen” Daten (Sy stemvariablen), die im Supervisorspeicher¬ 
bereich untergebracht sind, durch ein User-Programm ergibt. 


Der Programmzähler der CPU ist zwar 32 Bit breit, herausgeführt auf den Adreßbus sind 
jedoch nur die Adreßleitungen Al.. A23. Die Adreßleitung A0 existiert beim MC68000 nicht, 
da ja mit einem 16-Bit-Datenbus gearbeitet wird. Um aber auch auf ungerade Adressen (ein¬ 
zelne Bytes) zugreifen zu können, liefert die CPU die lo w-aktiven Steuersignale UDS und LDS 
(Upper-Data-Strobe und Lower-Data-Strobe). 
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ISmII Interrupt-MasKe 


X H Z U C Statusregister 


X Extend-Bit 
N Negative-Bit 
Z Zero-Bit 
y Overflow-Bit 
C Carry-Bit 


Abb. 1.1: Die Register des MC68000 


UDS ist aktiv (Low), wenn auf das höherwertige Byte eines Wortes zugegriffen wird (Bits 
8.. 15 des Datenbusses, gerade Speicheradresse), und LDS ist entsprechend aktiv (Low) bei 
einem Zugriff auf das niederwertige Byte (Bits 0. .7 des Datenbusses, ungerade Speicheradresse). 
Logischerweise sind also dann bei einem Wortzugriff beide Leitungen aktiv! 

Mit den Adreßleitungen A1..A23 lassen sich also “nur” max. 16 MBytes an Speicherraum 
direkt ansprechen, diese 16 MByte jedoch durchgehend linear ohne Segmentierung wie z, B. 
bei den 8086/8088-CPUs. Dieser Adreßraum von 16 MB yte wird im ATARI ST, wie in Abbil¬ 
dung 1.2 gezeigt, eingeteilt. 
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Abb. 12: Die Speicheraufteilung des ST im Überblick 
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RAM und ROM 

Die ersten zwei KByte des Adreßraums des ST sind für die Ausnahmevektoren und den 
Supervisor-Stack reserviert und liegen (fast ausschließlich) im RAM. Dabei belegen die im 
ST benutzten Ausnahmevektoren die ersten zwei Pages des Speicherraums (von $8 bis $ 13C). 
Ab Adresse $380 schließt sich daran der Bereich mit den verschiedenen Systemvariablen an 
(siehe Teil 1, Kapitel 1, “BIOS und XBIOS”). 

Bei den ersten acht Bytes ab Adresse $0 handelt es sich nicht um RAM, sondern um ROM! 
Es sind dies die ersten achtBytes des ST-ROMs ab Adresse $FC 0000, die durch entsprechende 
Adreßdecodierung an diese Stelle des Adreßraums gedoppelt werden. Der Inhalt dieser beiden 
Langwörter sorgt dafür, daß nach dem Einschalten des ST oder nach einem RESET das gesam¬ 
te Computersystem von einem definierten Ausgangspunkt hochgefahren werden kann. 

Die 68000er-CPU erwartet nach einem RESET nämlich in Adresse $0 einen Anfangswert für 
den Supervisor-Stackpointer und in Adresse $4 einen Pointer auf die Adresse des ersten 
auszuführenden Befehls! 

Wer jetzt mal schnell bei Adresse $0 nachgeschaut hat, wundert sich bestimmt über diesen 
seltsamen Wert, der dort als Startweit für den Supervisor-Stackpointer aufbewahrt wird. Keine 
Bange, der Wert stimmt schon, nur enthält das Langwort (eigentlich ja bei $FC 0000 im ROM 
gelegen) einen Sprungbefehl auf die Systemstart-Routinen im ROM. Das ist aber nicht weiter 
tragisch, da der ST nach einemRESET Zunächst sowieso nicht weiß, welche Speicherbestückung 
für das RAM vorliegt. Zuerst muß nämlich mit Hilfe der MMU und den eingebauten RAM- 
Chips ein durchgehender Speicherbereich “zusammengebaut” werden. Dazu später noch ein 
wenig mehr. 

Die Geräte 260ST und 520ST(FM) besitzen in ihrer Grundausstattung eine Speicherkapazität 
von 512 KByte RAM. Somit endet für diese Geräte der RAM-Bereich bei $07 FFFF. Diese 
512 KByte werden mittels 16 Dynamischer RAM-Chips des Typs 41256 realisiert, welche pro 
Chip eine Speicherkapazität von 256K x 1 Bit aufweisen. 

Die Datenleitungen dieser 16 Chips werden zu einem 16-Bit-Datenbus zusammengefaßt, denn 
dieCPUkannjalöBitauf einmal verarbeiten. Fürdie Adressierung der262144 Speicherstellen 
in den Speicherchips wird ein gemultiplexter Adreßbus verwandt. Man legt dazu zeitlich 
nacheinander erst die untere und dann die obere Hälfte der in diesem Fall benötigten 
Adreßinformation an die Speicherchips. 

Deshalb genügen dann für einen 256 KBit-Chip auch statt der sonst erforderlichen 18 (2 A 18 
= 262144) nun 18/2 = 9 Adreßleitungen und je eine sogenannte RAS- und CAS-Leitung. Die 
RAS- und CAS-Leitung (RAS = Row Adress Strobe = Zeilen-Adreßimpuls / CAS = Column 
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Adress Strobe = Spalten-Adreßimpuls) signalisieren der Logik in den Speicherchips, welcher 
Teil der benötigten Adresse gerade an den Adreßeingängen des Chips anliegt. 

Man spart so Platz, Anschlüsse und Leitungen, benötigt aber etwas zusätzliche Logik für das 
Multiplexen und das Timing. Im ST befindet sich diese Logik in der sogenannten Memory- 
Management-Unit (MMU). 


Standardchips erleichtern den Speicherausbau 

Bereits bei der Entwicklung der ST-Serie wurde von ATARI Wert auf eine möglichst einfache 
Verwendbarkeit von Standard-RAM-Chips gelegt. 

So unterstützt die derzeit in den ST verwendete MMU zwei RAM-Speicherbänke mit dynami¬ 
schem RAM zu max. 2 MByte pro Bank. Die STs des Typs 260ST und 520ST(FM) besitzen 
nur eine Speicherbank mit 16 Chips des 256KBit-Typs und kommen so auf 512 KByte RAM. 

Um nun bei den Geräten des Typs 520ST+ und 1040ST(FM) auf einen Speicherausbau von 
1 MByte RAM zu kommen, wurde einfach die zweite Speicherbank mit weiteren 16 Chips 
des 256 KBit-Typs eingebaut. Diese Aufrüstung ist relativ problemlos, denn außer den Chips 
braucht man keine zusätzlichen Multiplexer und Adreßdecoder. Die MMU liefert bereits von 
Haus aus die hierfür zusätzlich erforderl ichen RAS- und CAS-Signale für die zweite Speicher¬ 
bank. 

Für die zusätzlich erforderlichen 16 Chips der zweiten Bank ist das Platinenlayout des 
1040ST(FM) bereits vorgesehen. Beim 520ST+ (oder nachträglich beim 260ST oder 
520ST(FM)) lassen sich die Chips für die zweite Speicherbank einfach auf die Chips der ersten 
Bank “huckepack” auflöten. Lediglich die RAS- und C AS-Anschlüsse werden nicht direkt mit 
den darunterliegenden Chipanschlüssen verlötet, sondern separat mit der MMU verbunden. 

Dabei werden alle R AS-Anschlüsse (Pin 4 der Speicherchips) der neuen Bank verbunden und 
an den Anschluß RAS 1 (Pin 18) der MMU geführt. Die CAS-Anschlüsse (Pin 15 der Speicher¬ 
chips) der acht Chips, die mit den Datenleitungen D0...D7 des Datenbus (niedrigwertiges 
Byte) verbunden sind, werden gebrückt und über einen 68 Ohm-Widerstand an CAS 1L (Pin 
21) der MMU gelegt. 

Entsprechend ist mit den CAS-Anschlüssen der acht Chips zu verfahren, die an die Datenlei¬ 
tungen D8...D15 (höherwertiges Byte) des Datenbusses angeschlossen sind. Sie werden 
ebenfalls gebrückt und auch über einen 68 Ohm-Widerstand mit CAS 1H (Pin 22) der MMU 
verbunden. Für den Aufbau der Speicherbänke können verschiedene Typen von dynamischen 
RAM-Chips verwendet werden, wie Abbildung 1.3 zeigt. 
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Abb. 1.3: Die im ST verwendbaren RAM-Chips 


1 MBit-Chips passen leider nicht! 

Die 64 KBit- und 256 KBit-Chips sind untereinander pinkompatibel und können direkt 
ausgetauscht werden. Ein direkter Tausch der 256 KBit- gegen 1 MBit-Typen ist aber leider 
nicht möglich (unterschiedliches Pin-Layout!). 

Will man einen “Nicht-MEGA ST” mit 1 MBit-Chips bestücken, so sind einige Modifikationen 
bei den Chipanschlüssen erforderlich, die einen versierten Hardware-Bastler jedoch nicht vor 
unüberwindliche Probleme stellen dürften! Auch werden inzwischen von verschiedenen 
Firmen Aufrüstplatinen angeboten, die mit oder ohne Entfernen der alten Speicherbank 
eingebaut werden können und wahlweise eine Bestückung mit 256 KBit- oder mit Megabit- 
Chips erlauben, Aufrüstungen auf bis zu 4 MByte sind auch für “Nicht-MEGA ST-Computer” 
möglich. Grenzen sind nur durch den eigenen Geldbeutel gesetzt. Die Geräte der MEGA ST- 
Serie besitzen von Haus aus die Megabit-Chips und kommen somit auf einen Speicherausbau 
von 2 MByte bei einer Bank bzw. 4 MByte, wenn auch die zweite Bank auf der Hauptplatine 
bestückt ist. 

Wegen der 1988/89 teilweise auftretenden Speicherknappheit hat ATARI insbesondere bei 
den Rechnern der 1040er-Serie verschiedene Platinenlayouts verwendet, um eben alle nur 
möglichen Speicherchips verwenden zu können. So kamen unter anderem auch 1 MBit- 
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RAMs der Organisation 256K x 4 Bit zum Einsatz. Die Bestückung der damit ausgerüsteten 
1040er sieht dann so aus, daß pro Speicherbank vier Chips zum Einsatz kommen und damit 
512 KByte Kapazität aufweisen. 

Um auf die Standardkapazität von 1 MByte pro Rechner zu kommen, wurde die zweite Bank 
genauso bestückt. Acht Chips ergeben somit eine Kapazität von 1 MByte! Eine Erweiterung 
auf 2 MByte oder 4 Mbyte ist bei diesen Rechnern aber nicht mehr im einfachen “Huckepack- 
Verfahren” möglich. 

Bei einer evtl. Speichererweiterung ist darauf zu achten, daß jede Bank einheitlich mit den 
gleichen Chips bestückt werden muß. 

Es ist aber ohne weiteres möglich, in den beiden möglichen Speicherbänken unterschiedliche 
Chiptypen zu verwenden. So kann man z. B. die erste Bank mit 256 KBit-Chips bestücken und 
kommt dann auf 512 KByte RAM. Die zweite Bank kann mit Megabit-Chips bestückt sein 
und weist dann eine Kapazität von 2 MByte auf. 

Zusammen sind das dann stattliche 2,5 MByte! (Leider gibt es einige STs mit MMUs der Firma 
IMP, die eine ungleiche Bestückung der beiden Speicherbänke nicht erlauben!) Durch diese 
Möglichkeit der gemischten Bestückung ergeben sich eine Reihe von möglichen Speicher¬ 
konfigurationen. 


$FF 8081 XX XX 


0 0 


UH- 


10 


11 


MermrH-Confjquration-Rgaistcr 
Rank 8 


- 128 KByte C64 kBit-Chipsl 

- 512 Kbyte C256 kBit-Chipsl 

- 2 MByte tl MBit-Chipsl 

- reserviert 

Bank 1 

- 128 KByte (64 kBit-Chipsl 

- 512 Kbyte (256 kBit-Chipsl 

l|D|- 2 MByte (1 MBit-Chipsl 

reserviert 


0 Bl 


0 1 


11 


Abb. 1.4: So programmiert der ST seinen Speicherausbau 
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Setze Menory-Cortf i guration-Register auf nax. 
Möglichen Speicherausbau! CJe Bank auf 2 MBytes 

Schreibe Testnuster in die Speicherstellen 
$08 8688 - $88 81FF. und $28 8888 - $28 81FF! 

Bank 8 Bank 1 

Lese Muster aus Speicherbereich 

$28 8288 - $20 83FF [Liegt in Bank 1J 

^^iibereinstinnung Mit geschriebenen Muster?__ 

Ja“ -——-—' ' 1 Hein 

Bank 1 hat 
128 KByte! 

Lese Muster aus Speicherbereich 
$28 8408 - $20 85FF. 

(Liegt in Bank 1) 

sjibereinstinnung nit geschriebenen 

Muster? _ _-——- 

J a ^ _____ ““'"'ifein 

Bank 1 hat 
512 KByte! 

Lese Muster aus Speicher¬ 
bereich $28 8088 - $28 81FF 
(Liegt in Bank 11 

Übereinstinnung nit 
^geschriebenen Rüster?^- 

Ja ‘—— ——"'Nein 

Bank 1 hat Bank 1 nicht 

2 MByte! vorhanden! 

Setze Menorg-Configuration-Register für Bank 1 
entsprechend der gefundenen Bestückung. 


I Die gleiche Prozedur wird für die Speicher- 
■ bank 0 durchgeführt! 

i Anschließend wird für die Bank B ebenfalls 
i das Menorg-Configuration-Register entsprechend 
der gefundenen Bestückung gesetzt. 


Die Große des gefundenen RAM-Arbeitsspeichers 
wird in 1 phystop' CS42EJ abgelegt. 


Weiter nit der Systeninitialisierung 


Abb. 1.5: So stellt der ST beim Systemstart seinen Speicherausbau fest 


Wieviel RAM ist denn drin? 

Um festzustellen, welcher Speicherausbau denn nun vorliegt, wird zu Beginn der Sy steminitia- 
lisierung ein Speichertest ausgeführt, der Aufschluß darüber gibt, welche Speicherchips 
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vorhanden sind. Der Programmteil liegt im ROM und wird nahezu unmittelbar nach dem 
Systemstart ausgeführt. 

Hierbei wird folgender Effekt ausgenutzt: 

Man geht zunächst beim Speichertest davon aus, daß beide Speicherbänke vorhanden sind und 
mit Megabit-Chips bestückt sind. 

Die ersten zwei Pages ($0.. .$ 1 ff) jeder Bank werden nun mit einem Testmuster beschrieben. 
Befinden sich jedoch statt der Megabit-RAMs, die ja unterstellt werden, solche des 64 KBit- 
oder 256 KBit-Typs im Rechner, so werden durch eine Art Falschdecodierung der 
Adreßleitungen zu den Speicherchips nicht nur die ersten beiden Pages der Speicherbank mit 
dem Testmuster beschrieben, sondern je nach verwendeten Chips noch andere Pages! 

Aus der Information, welche Pages noch beschrieben wurden, kann auf die Art der eingebauten 
Speicherchips geschlossen werden. 

Das sogenannte Memory-Configuration-Register (Label: “memconf’) bei Adresse $FF 8001 
wird dann entsprechend gesetzt, so daß auch bei unterschiedlicher Bestückung der beiden 
Bänke ein durchgehender RAM-Speicherbereich vorliegt. Das “Schattenregister” des “mem¬ 
conf-Registers befindetsich, für den Programmierer besser zugänglich, bei den Systemvaria¬ 
blen als Bytewert (jedoch nur unteres Nibble interessant!) an Speicherstelle $424 (Label: 
“memcntrl”). Soviel zum RAM des ST! 


Nichtflüchtige Speicherbereiche 

Wie bereits aus dem Bild zur Speicheraufteilung des ST hervorgeht, liegen im Adreßraum der 
CPU zwei Speicherbereiche, die für ROM-Bestückung vorgesehen sind. Als erstes soll der 
Bereich ab Adresse $FC 0000 betrachtet werden. Hier ist ein Speicherbereich von 192 KByte 
für das Betriebssystem (TOS) des ST vorgesehen. Inzwischen werden alle ST-Systeme mit 
Betriebssystem-ROMs ausgeliefert. 

Die 260ST- und 520ST+ -Rechner enthielten nur zwei 8Kx8 Bit “Boot-ROMs” in zwei der 
insgesamt sechs vorgesehenen Fassungen für die Betriebssystem-ROMs. Damit konnte das 
eigentliche TOS von einer Systemdiskette in den RAM-Arbeitsspeicher geladen (gebootet) 
und gestartet werden. Auf diese Weise gehen aber immerhin 192 KByte vom RAM für das 
Betriebssystem drauf! Die Boot-ROMs belegen den Adreßraum von $FC 0000 bis $FC 3FFF. 

In diesen 16 KByte ROM ist ein Programmabschnitt für die Grundsysteminitialisierung 
enthalten sowie Daten für die Bildinformation, die vom angeschlossenen Monitor wiederge- 
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Abb. 1.6: Pinbelegung der im ST verwendbaren ROMs 


geben wird, während das eigentliche TOS von der Systemdiskette in den Arbeitsspeicher 
geladen wird. 


Geballte “Intelligenz” sofort verfügbar - TOS im ROM 

Bei den von ATARI ab Ende 1986 ausgelieferten Rechnern der ST-Serie ist das komplette 
Betriebssystem in sechs ROM-Chips der Organisation 32K x 8 Bit oder in zwei ROM-Chips 
der Organisation 128K x 8 Bit enthalten. Die ROM-Chips sind von ATARI auch als Set se¬ 
parat erhältlich, so daß auch ältere ST-Rechner mit ROM-TOS nachgerüstet werden können, 
die Steckplätze sind ja vorhanden. 

Mit Erscheinen der MEGA ST-Serie wurde erstmals eine neue Version von ROM-TOS 
(Version 1.02) ausgeliefert, welche den BLITTER (deshalb auch als BLITTER-TOS bezeich¬ 
net) und den neuen Hardware-Uhr-Chip unterstützt. Eine weitere, überarbeitete TOS-Version 
(1.04) steht seit Mitte März 1989 auf ROMs zur Verfügung. 

In neueren ST-Systemen (sowohl MEGA ST als auch 1040ST(FM) können durch geänderte 
Platinen-Layouts erstmals auch Megabit-ROM-Chips verwendet werden. 
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Das bedeutet, daß für das TOS nur noch zwei Chips mit je 128K x 8 Bit Kapazität erforderlich 
sind und diese noch nicht einmal voll ausgenutzt werden! InAbbildung 1.7ist der Schaltungsaus¬ 
zug wiedergegeben, der zeigt, wie die Einbindung der Betriebssystem-ROMs beim MEGA 
ST und bei Geräten der 1040er-Serie vorgenommen wurde. 



Ahh. 1.7: Schaltung der ROM-Bank für MEGA ST und 1040STF(M) 
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Da je ROM-Chip ein Byte pro Adresse angesprochen wird, bilden immer zwei Chips ein 
Pärchen, um den 16-Bit-Datenbus mit ROM-Informationen zu versorgen. Wenn 256 KBit- 
ROMs (oder EPROMs) verwendet werden, sind alle sechs Chipfassungen belegt. Dabei ist die 
Aufteilung des Adreßraums entsprechend der nachfolgenden Tabelle vorgenommen: 


Adreßbereich 

Chip-# 
MEGA ST 

Chip-# 

1040ST 

Chip aktiviert 
bei Low auf 

Inhalt 

$FC 0000 bis 

U 10 

U 67 

_ROM2 

Low-Byte 

$FC FFFF 

U 9 

U 63 

JROM2 

High-Byte 

$FD 0000 bis 

U 7 

U 62 

JROM1 

Low-Byte 

$FD FFFF 

U 6 

U 59 

JR.OM1 

High-Byte 

$FE 0000 bis 

U 4 

U 53 

_ROM0 

Low-Byte 

$FE FFFF 

U 3 

U 48 

_ROM0 

High-Byte 


Die Chip Enable(_CE)-Information auf den Leitungen _ROMO.._ROM2 werden dabei vom 
GLUE-Chip geliefert. Je nach “gewünschtem” Adreßbereich wird somit vom GLUE das 
entsprechende ROM-Chip-Pärchen aktiviert. 

Bei Verwendung von Megabit-ROMs kommt man locker mit zwei Chips (2 x 128 
KByte = 256KByte) aus, um das komplette TOS darin unterzubringen. Allerdings muß dazu 
natürlich dafür gesorgt werden, daß sich dieses Chip-Pärchen über den gesamten ROM- 
Adreßbereich von $FC 0000..$FE FFFF“angesprochen” fühlt und auch alle Adreßleitungen 
am Chip vorhanden sind. Das Platinenlayout beim MEGA ST und 1040 STF(M) ist entspre¬ 
chend ausgelegt. Die Mega-Bit-ROMs müssen dazu in die Fassungen für U63/U9 und U67/ 
U10 eingesetzt sein. Über entsprechende Lötbrücken wird die korrekte Einbindung der ROM- 
Chips dann folgendermaßen vorgenommen (siehe dazu Abbildung 1.7!): 

- Brücke “W2” auf Stellung “IM” versetzen, um die Adreßleitung A 17 der CPU an die 
Megabit-ROM-Chips (Pin 22 = A 16-Anschluß des ROMs) zu führen. (Bei 256KBit- 
ROMs ist der Chipanschluß (Pin 22) das “Output Enable (_OE)”-Signal und fest auf Low 
zu legen.) 

- Brücke “W3” ebenfalls auf Stellung “ IM” bringen. Damit wird die Adreßleitung A 16 
der CPU an Pin 1 (- A 15-Anschluß) der Megabit-ROM-Chips geführt. (Bei 256KBit- 
ROMs ist Pin 1 des Chips intern nicht angeschlossen, bzw. bei EPROMs muß dort +5V 
angelegt werden. Bei eingelegter Brücke “ W3” wird an alle Pin 1 der ROM-Fassungen 
+5V angelegt!) 
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Die Brücke “W4” darf nicht eingelegt sein. Das 3fach NAND-Gatter in U12/U68 faßt 
dann die Signale _ROMO.._ROM2 zu einem einzigen “Chip Enable (_CE)”-Signal für 
die Megabit-ROM-Chips zusammen. Damit ist gewährleistet, daß die beiden Megabit- 
ROMs im gesamten TOS-ROM-Adreßbereich aktiviert sind! (Bei 256KBit-ROMs 
braucht jedesROM-Pärchen eineigenes “Chip Enable (_CE)”-Signal(_ROMO.._ROM2). 
Die Funktion von U12/U68 ist deshalb durch Auftrennen der Brücke am Ausgang des 
NAND-Gatters aufzuheben. Wichtig! Leider ist durch einen Platinen-Layout-Fehler bei 
den MEGA STs diese Brücke nicht vorhanden. Trennen geht also hier nur durch z. B. 
Auslöten des gesamten Gatterbausteins U12 oder durch Kappen des Pins 12 von U12!) 

In Abbildung 1.7 ist die Bestückung der Brücken (sie werden im MEGA ST übrigens durch 
0 OHM-Widerstände realisiert!) für 256KBit-ROMs eingezeichnet. Wo findet man nun den 
Gatterbaustein U12 (MEGA ST) bzw. U68 (1040STF(M)) auf der Platine? 

Beim MEGA ST befindet sich Ul 2 in der linken, unteren Ecke der Platine, direkt links neben 
der Quadratischen MMU. In der Nähe befinden sich auch die Brücken “W2”bis “W4”! Wegen 
der vielen Platinenversionen beim 1040STF(M) kann man als Anhaltspunkt nur sagen: In der 
Nähe der ROM-Fassungen auf die Suche gehen. Die Brücken sind beim 1040STF(M) durch 
Lötspiegel realisiert und wegen der Beschriftung der Platine relativ gut zu finden! 

Würde ATARI einen anderen GLUE-Chip verwenden (dieser liefert unter anderem die Chip- 
Select-Signale _ROMO.._ROM2 für die ROM-Chips), so ließen sich in den 6 Chip-Fassungen 
768 KByte ROM unterbringen. Die Schaltung und das Platinenlayout sind dafür bereits aus¬ 
gelegt! 

Nach einem RESET oder bei einem Kaltstart ist ein Rechner mit ROM-TOS also sofort “voll 
da”, während dieser Vorgang mit einem von Diskette zu ladenden TOS ca. 35 Sek. dauert. 

Außerdem steht bei TOS im ROM dann natürlich ein schönes Stück RAM mehr zur Verfü¬ 
gung, welches ja sonst vom einzuladenden TOS-Betriebssystem belegt wird. Es ist aber auch 
mit TOS im ROM weiterhin möglich, Boot-Disketten mit z. B. modifizierten oder neuen TOS- 
Versionen zu starten. 


Das Cartridge-System des ST 

Aber nicht nur das Betriebssystem kann in ROMs untergebracht werden! Der Adreßraum von 
$FA 0000 bis SFB FFFF kann durch ein ROM-Cartridge (Einsteckplatine mit ROM- bzw. 
EPROM-Chips) belegt werden, welches ein oder mehrere Programme enthalten kann. Es 
stehen 128 KByte Speicherplatz für ein solches Cartridge zur Verfügung. Die eventuelle 
Verwendung solcher Cartridges ist im Betriebssystem schon vorgesehen worden. 
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Der Vorteil von Software auf Cartridge liegt einmal in der schnellen Handhabung, denn das 
Laden vom Massenspeicher entfällt. 

Als weiterer Pluspunkt ist anzuführen, daß ja kein Platz im RAM für diese Software benötigt 
wird. Dies gilt jedoch nur dann, wenn die Programme auch wirklich im Cartridge-ROM ablau¬ 
fen und nicht erst über ein Treibeiprogramm ins RAM kopiert und dann dort gestartet werden 
(wie es z. B. bei einer RAM-Disk gemacht wird)! 


Ein neues Betriebssystem für den ST? 

Entsprechend der Behandlung des Cartridge-Anschlusses in der Betriebssystem-Software ist 
es sogar möglich, mittels Cartridge ein neues Betriebssystem auf dem ST zu fahren! So 
existiert bereits als Cartridge das Betriebssystem “RTOS-UH” (Realtime Operating System 
- Uni Hannover) mit Compiler für die Programmiersprache “PEARL”. Dieses Betriebssystem 
erlaubt das komfortable Bearbeiten von Echtzeit-Steuerungsaufgaben bei “gleichzeitiger” 
Ausführung mehrerer Aufgaben (Multitasking). 

Ein sogenannter MAC-Emulator, mit dem das Betriebssystem des Apple-Macintosh erfolg¬ 
reich auf dem ST nachgebildet wird, ist auch mit Cartridge-Unterstützung erhältlich! Dazu 
werden die Original Macintosh-ROMs in das Cartridge eingesetzt und mit einer Anpassungs¬ 
software das Betriebssystem des MAC gestartet. 

Anschlußplatinen für den Einsatz von “Selbstgebrannten” EPROMs mit eigener Software 
sowie EPROM-Programmiergeräte zum Anschluß an den Cartridge-Slot sind ebenfalls von 
Drittanbietem lieferbar. 

Weiterhin gibt es bereits Anschlußplatinen für den Cartridge-Port, mit denen die 128 KByte- 
Grenze “durchstoßen” wird. 512 KByte und mehr an residenter Software sind mittels Bank- 
Switching-Technik am Cartridge-Port abrufbar. Man unterteilt dazu den Speicherraum von 
512 KByte oder mehr in einzelne Blöcke von z. B. 64 KByte. Eine entsprechende Treibersoftware 
(ebenfalls auf dem Cartridge) sorgt dann dafür, daß die CPU im Cartridge-Adreßraum immer 
den gerade notwendigen Block “zu sehen” bekommt, der gerade angesprochen werden soll. 

Im TOS-Magazin 8/90 und 9/90 habe ich außerdem beschrieben, wie man den Cartridge-Port 
des ST als I/O-Port für einfache Steuer- und Überwachungsaufgaben verwenden kann. Folgen¬ 
de Signale stehen am Cartridge-Port zur Verfügung: 

D0...D15 Der 16 Bit breite Datenbus (ungepuffert!) der CPU 

A1...A15 Die unteren 15 Adreßleitungen (ungepuffert!) der CPU 
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Abb. 1.8: Die Belegung des Cartridge-Anschlusses (von außen auf den Anschluß gesehen) 


LDS/UDS Lower-/Upper-Data Strobe (Aktiv=low!). Dient zur Decodierung, ob Wort¬ 
oder Einzelbyte-Zugriff erfolgen soll. 

ROM3 sei. Wird Low, sobald eine Adresse im Bereich von $FB 0000 bis $FB FFFF ange¬ 
sprochen wird (64 KByte-Block). Als “Chip-Select"-Signal für die ROM- 
Chips eines Cartridges benutzbar. 

ROM4 sei. Wird Low, wenn eine Adresse im Bereich von $FA 0000 bis $FA FFFF aus¬ 
gelesen wird (64 KByte Block). Ebenfalls als “Chip-Select” für Cartridge- 
ROM-Chips benutzbar. 

+5V Versorgungsspannung für das Cartridge 

GND Masseanschluß für das Cartridge 

Wer bereits mit den 8-Bit-Computem von ATARI gearbeitet und sich mit dem dort ebenfalls 
schon realisierten Cartridge-Konzept beschäftigt hat, dem wird das Prinzip vertraut Vorkom¬ 
men. 

Gegenüber dem Cartridge-Slot der 8-Bit-Rechner hat man leider beim ST nicht mehr die 
Möglichkeit, in das Cartridge zu schreiben. Es ist aber nicht so, daß für die R/W-Leitung kein 
Platz mehr gewesen oder diese nur “vergessen” worden wäre. 
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Abb. 1.9: So könnte die Schaltung für ein 128 KByte-Cartridge aussehen 

Bei jedem Schreibversuch in den Adreßbereich $FA 0000 bis $FE FFFF meldet der GLUE- 
Chip der CPU einen “BUS-ERROR”. Schreibzugriffe in diesen Bereich sind also nicht 
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erwünscht und vorgesehen! Außerdem hat ATARI bei der Realisierung des Cartridge-Slots 
für die Direktsteckvorrichtung ein unübliches Rastermaß von 2 mm verwandt. Warum man 
hier nicht auf dem sonst üblichen Maß von 1/10 Inch = 2,54 mm geblieben ist, ist nicht ohne 
weiteres nachvollziehbar. 

Von Drittanbietem sind aber Adaptersteckverbinder von 2mm -> 2,54mm Raster mit zum Teil 
Pufferbausteinen für die Adreß- und Datenbussignale lieferbar. 

Außerdem kann der Hardewarebastler auf Leerplatinen zurückgreifen, die zum Aufbau eige¬ 
ner Schaltungen am Cartridgeport verwendet werden können. 


Die Behandlung von Cartridge-Software durch das Betriebssystem 

Wie bereits erwähnt, wird vom Betriebssystem das Vorhandensein eines Cartridges schon bei 
der Systeminitialisierung berücksichtigt. So bestehen verschiedene Möglichkeiten, aus dem 
normalen “Hochfahren” des Computersystems “auszusteigen” und die weitere Kontrolle über 
den ST an die Cartridge-Software zu übergeben. 

Die “Anwesenheit” eines Cartridges wird vom Betriebssystem durch Lesen des ersten Lang¬ 
wortes ($FA 0000) im Cartridge-Speicherbereich überprüft. Abhängig von dem Wert dieses 
“magischen Langworts” wird evtl, schon direkt nach einem RESET die Kontrolle an das 
Cartridge übergeben oder erst zu einem späteren Zeitpunkt. Lautet der Inhalt des magischen 
Langworts auf SFA52 235F, so wird nahezu unmittelbar nach einem System-RESET nach 
Adresse $FA 0004 im Cartridge verzweigt. In Register A6 der CPU wird jedoch für den Fall, 
daß später die normale Systeminitialisierung fortgesetzt werden soll, eine RETURN-Adresse 
mit an die Cartridge-Software übergeben. 

Cartridge-Software, welche schon zu diesem Zeitpunkt die “Herrschaft” über den ST über¬ 
nimmt, muß alle Hardware-Komponenten des ST selbst initialisieren, die benutzt werden sol¬ 
len. Anwendung findet dieser frühzeitige Ausstieg aus der Systeminitialisierung z. B. beim 
Geräte-Test im Reparaturservice. 

Mittels eines sogenannten Diagnostic-Cartridge ist es so möglich, den ST durchzuchecken. 
Es werden durch die Diagnose-Software alle Systemteile angesprochen, und aus entsprechen¬ 
den Rückmeldungen (oder eben auch nicht!) kann auf die Funktionsfähigkeit geschlossen wer¬ 
den. ImRegelfall wird Cartridge-Software jedoch auf ein voll initialisiertes System zurückgreifen 
wollen. Außerdem lassen sich auf einem Cartridge mehrere Programme unterbringen. 

In so einem Fall muß bei Adresse $FA 0000 der Inhalt des magischen Langwortes auf 
$ABCD EE42 lauten. Außerdem müssen im Cartridge noch einige Angaben mehr enthalten 
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sein. So ist für jcdes Programm ein sogenannter “Programm-Vorspann” (Cartridge-Application- 
Header) erforderlich, der folgendermaßen aufgebaut sein muß: 


Adresse 

Label 

Bedeutung 

SFA 8888 

CA-HAGIC 

'Magisches' Languort 

$FA 8884 

CA-NEXT 

Zeiger auf nächsten Progrannkopf 

SFA 0888 

CA-INIT 

Zeiger auf Progranninitialisier. 

SFA 888C 

CA.RUN 

Progrannanfang 

SFA 8818 

CA_TIHE 

Ersteilungs- oder Änderungszeit 

SFA 8812 

CA-DATE 

Erstellungs- oder Xnderungsdatun 

SFA 8814 

CA-SIZE 

PrograMnlänge 

SFA 8818 

CA-NAME 

Progrannnane 


Adresse 

Inhalt 

Bedeutung 

CA-NEXT 

CA-NEXTl 

Zeiger auf nächsten Progrannkopf 

* $84 

CA-INIT1 

Zeiger auf Progranninitialisier. 

+ $84 

CA-RUN1 

Progrannanfang 

+ $84 

CA-TIME1 

Erstellungs- oder Änderungszeit 

+ $82 

CA-DATE1 

Erstellungs- oder änderungsdatun 

+ $82 

CA-SIZE1 

Progrannlänge 

* $84 

CA-NAHEl 

Progrannnane 


Header 


Header 


Abb. 1.10: So sind die Programm-Vorspanne beim ST-Cartridge auf gebaut 


Die Label haben dabei im einzelnen folgende Bedeutung: 

CA„NEXT Wenn mehrere Programme auf dem gleichen Cartridge enthalten sind, enthält 
CA_NEXT einen Pointer auf den nächsten Programm vorspann. Ist nur ein Pro¬ 
gramm vorhanden oder ist der betrachtete Programmvorspann der letzte auf 
dem Cartridge, steht hier $0000 0000! 

CAJNIT Anfangsadresse einer evtl. Cartridge-Programm-Initialisierung. Die Bits 24.31 

bleiben für die Adressierung unberücksichtigt und enthalten Informationen, zu 
welchem Zeitpunkt der ST-Systeminitialisierung nach CA_INIT verzweigt 
werden soll. Ist das entsprechende Bit gesetzt, so erfolgt Ausführung. 

Bit 24 Initialisierung oder Start der Cartridge-Software nach erfolgter Hardwareinitiali¬ 

sierung. Die Betriebssystemvariablen und Interruptvektoren sind schon ge- 
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setzt. DieBildschirmauflösungist bereits ermittelt und eingestellt. Die Interrupts 
sind jedoch in der CPU noch gesperrt (Interrupt-Priority-Level auf 7). 

Bit 25 Initialisierung oder Start der Cartridge-Software wie bei gesetztem Bit 24, 

jedoch erst unmittelbar nach Freigabe der Interrupts in der CPU (Interrupt-Prio¬ 
rity-Level ist dann auf 3 gesetzt) und vor der GEMDOS-Initialisierung. 

Bit 26 Initialisierung oder Start der Cartridge-Software etwas früher, als für Bit 24 be¬ 

schrieben. Einstellung der aktuellen Bildschirmauflösung ist noch nicht erfolgt. 

Bit 27 Cartridge-Programm-Initialisierung oder -Start erfolgt erst unmittelbar vor 

einem evtl. Disk-Boot. Sonst wie bei Bit 25. 

Die Bits 29 ..31 sind nur dann von Bedeutung, wenn Cartridge-Programme als GEMDOS- 
Anwendungen laufen. (Es ist mir allerdings noch nicht gelungen, Parameter an eine TTP- 
Anwendung im Cartridge zu übergeben, wie man das bei “normalen” TTP-Programmen 
problemlos mittels der Dialogbox bewerkstelligen kann. Die Angaben für die Bits 29...31 
beruhen auf Informationen aus dem “Hitchhiker’s guide to the BIOS” von ATARI.) 

Bit 29 Programm gehört zum Desktop (Accessory) 

Bit 30 TOS-Applikation 

Bit 31 TOS-Applikation mit der Möglichkeit, Parameter an das Programm zu überge¬ 

ben. (TTP-Anwendung =TOS takes Parameters) 

CA_RUN Adresse des Programmanfangs eines Cartridge-Programms. Anderhier angege¬ 

benen Adresse beginnt das eigentliche Programm. Alle evtl, nötigen Initialisie¬ 
rungen sind schonerfolgt. Nur nötig, wenn Programm unter GEMDOS läuft. 

CA_TIME Uhrzeit der Programmerstellung im Format (dient nur zur Information des 
Benutzers). 

High- Low- 

Byte Byte 

hhhhhmmm mmmsssss 

Sekunden in 2er Schritten (0..29) 
Minuten (0..59) 

Stunden (0..23) 
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CA_D ATE Datum der Programmerstellung im Format (dient ebenfalls nur zur Information 
des Benutzers.) 


High- Low- 

Byte Byte 


YYYYYYYM MMMDDDDD 



Tag (1 ..31) 

Monat (1.. 12) 

Jahr (0..119) seit 1980! 


CA_SIZE Größe des Einzelprogramms. Wird eigentlich nicht benötigt! 

CAJNAME Name des Programms im GEMDOS-Format (FILENAME.EXT+$00), also 
max. acht Zeichen für den Programmnamen, evtl, drei Zeichen für die Erweite¬ 
rung mit dazwischenliegendem Trennungspunkt, abgeschlossen durch $00. 
Nur zur Information des Benutzers. 

Cartridge-Programme, die unter GEMDOS laufen, sind auf dem virtuellen Laufwerk c: zu 
finden (der Laufwerksbezeichner ist ein kleines “c”). 

Gestartet werden die Programme mit dem gewohnten Doppelklick auf das gewünschte 
Programmsymbol. Software, die im Cartridge laufen soll, muß für den entsprechenden 
Adreßbereich (ROM!) geschrieben sein, in dem sie später ablaufen soll, oder voll relokatibel 
angelegt sein. GEMDOS hat jakeine Möglichkeit, anhand eines Programm-Headers irgend¬ 
welche Adressen im TEXT- oder DATA-Bereich im Cartridge (ROM!) zu relozieren. 

Cartridge-Programme, die RAM-Speicher benötigen (Pufferspeicher u.ä.), müssen sich die¬ 
sen Speicher “zuteilen” lassen (über die GEMDOS-Funktion “Malloc”) und selbst verwalten. 
Ein BSS-Bereich (Bereich für nichtinitialisierte Daten, wie er z. B. für Zwischenspeicherung 
von Benutzereingaben benutzt wird) ist ja im ROM schlecht zu realisieren! 

Beim Aufruf eines Cartridge-Programms legt GEMDOS auch eine Basepage an, die aber im 
wesenüichen nur die Startadresse des Programms und einen Pointer auf den Anfang der 
eigenen Basepage sowie die Basepage des aufrufenden Programms enthält. 


Soviel zum Cartridge-Slot des ST, 
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Abb. 1.11: So erscheinen Cartridge-Programme auf dem Desktop 


DMA im ST 


Die Konstrukteure des ATARI ST haben der CPU einen tatkräftigen Helfer zur Seite gestellt, 
der zwar nicht besonders viel “Intelligenz” besitzt, dafür aber ganz schön schnell arbeiten 
kann. 

Es handelt sich hierbei um eine DMA-Einheit, die von ATARI ebenfalls speziell für die ST- 
Serie entwickelt wurde. Mittels DMA = Direct Memory Access (zu deutsch etwa: direkt auf 
den Hauptspeicher zugreifend) ist es möglich, große Datenmengen von und zu Peripheriegeräten 
wie z. B. Floppy-Disk- und Hard-Disk-Stationen ohne Umwege über die CPU und deren Regi¬ 
ster zu transportieren. Der DMA-Baustein kann dabei gleichberechtigt mit der CPU auf das 
RAM zugreifen. Wer zuerst kommt, darf an die Daten! 


Datentransfer mit Turbolader 

Durch den DMA-Baustein bedient der ST den Floppy-Disk-Controller (FDC) und das soge¬ 
nannte ACSI (ATARI Computer System Interface). Der Datenstrom vom und zum Floppy- 
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Disk-Controller könnte mit einer Transferrate von bis zu 500 KBit/Sekunde “fließen”, wobei 
der eingebaute FDC jedoch nur eine Übertragungsrate von 250 KBit/s verkraftet. Beim ACSI 
handelt es sich um einen 8 Bit breiten Bus zum Anschluß von schnellen Peripheriegeräten wie 
z. B. eine Festplatte odereinen Laserdrucker. Die Datentransferrate beträgt hierbei immerhin 
8MBits/Sek (beider Harddisk-ca. 12MBits/Sek sind aber durchaus noch drin, wenn das Peri¬ 
pheriegerät da mitkommt!). 

Die CPU allein würde dabei schon ganz schön ins Schwitzen geraten und hätte kaum noch Zeit 
für andere “Hobbys”. Durch Verwendung der DMA-Einheit ist es nun nur noch erforderlich, 
diese entsprechend zu “informieren”, wo die zu transportierenden Daten im RAM abgelegt 
oder geholt werden (Startadresse) und wie viele Daten (Blocks zu je 512 Bytes) zum oder vom 
Peripheriegerät übertragen werden sollen. 

Damit die DMA-Einheit überhaupt wirkungsvoll arbeiten kann, ist sie darauf ausgelegt, 
Datenblöcke mit 512 B y tes (beim ST ist das sinnvollerweise die Größe eines Datensektors auf 
Disk) oder einem Vielfachen davon zu übertragen. 

Die weitere Abwicklung der Datenübertragung liegt nun beider DMA-Einheit, so daß die CPU 
mit anderen Aufgaben beschäftigt werden kann (vom TOS wird diese Möglichkeit leider nicht 
ausgenutzt!). 


Die Hälfte reicht auch 

Wie das Blockschaltbild zeigt, wird der 16 Bit breite Datenbus des Hauptspeichers durch die 
DMA-Einheit auf einen 8 Bit breiten Datenbus reduziert. Die Umsetzung eines 16 Bit-Daten¬ 
wortes in zwei aufeinanderfolgende 8-Bit-Datenworte erledigt die DMA-Einheit automa¬ 
tisch. Ein 16 Bit breiter Bus auf der Peripheriegeräteseite ist auch nicht erforderlich, da der 
Floppy-Disk-Controller (FDC) nur über einen 8-Bit-Datenbus verfügt. 

Der ACSI-Anschluß ist wegen seiner Anlehnung an den verbreiteten SCSI-Bus (SCSI=Small 
Computers System Interface) ebenfalls nur 8 Bit breit ausgefallen. 

Die DMA-Einheit verfügt intern Überfünf Register, mit denen die Steuerung des Datentransfers 
zum/vom Floppy-Disk-Controller und dem ACSI-Bus eingestellt werden kann. Ein 32 Byte 
großer Puffer nach dem FIFO-Prinzip (First In, First Out = zuerst eingebrachte Daten werden 
auch zuerst abgeholt) in der DMA-Einheit übernimmt die Pufferung zwischen dem Hauptspei¬ 
cher und dem Floppy-Disk-Controller/ACSI-Bus. 

Außerdem geschieht dort die Umsetzung eines 16-Bit-Datenwortes in zwei 8-Bit-Datenworte 
und umgekehrt. 



Die Zentraleinheit 


815 



Abb. 1.12: Die DMA-Einheit bedient den FDC und den ACSI-Bus 


Hierbei ist zu beachten, daß ein Transfer zwischen DMA-Einheit und Hauptspeicher immer 
erst dann erfolgt, wenn der Fifo-Buffer zu mehr als zur Hälfte gefüllt ist. 

Die DMA-Einheit versucht dann, die Buskontrolle zu übernehmen und 16 Bytes zu übertra¬ 
gen. Eine Übertragung erfolgt also immer in Bursts zu je 16Byte! Bei Datentransfers in Sektor¬ 
größe (512 Bytes) braucht man darauf nicht so sehr zu achten. 

Will man jedoch weniger als einen Sektor (512 Bytes) von Disk lesen, also z. B. nur Adreßfel- 
der (die sind nur 6 Bytes lang), so sollten mindestens drei dieser Felder gelesen werden, um 
auf eine Bytezahl von über 16 zu kommen. Sonst bleiben die gelesenen Daten im Fifo-Buffer 
hängen, und man wundert sich nach einer anscheinend doch korrekt ausgeführten DMA-Ope- 
ration, daß keine Daten im Hauptspeicher angekommen sind. 


So wie in der Abbildung 1.13 dargestellt, kann man sich ungefähr das Innenleben der DMA- 
Einheit des ST vorstellen. 
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Abb. 1.13: So ist die DMA-Einheit im Prinzip aufgebaut 


Für die Steuerung der Peripheriebausteine wie FDC und ACSI-Bus sind unter anderem die CR/ 
W-Leitung (Controller Read/Write = Lesen/Schreiben-Signalisierung für FDC oder ACSI- 
Bus (bei Low erfolgt Schreibzugriff)) und die HDCS-Leitung (Hard Disk Controller Select 
= ACSI-Bus-Zugriffssignalisierung) nötig. 

Über die FDCS-Leitung wird dem Floppy-Controller-Chip ein Zugriff signalisiert (Floppy- 
Disk-Controller-Select). DieCAl/CA2-Leitungen dienen als Adreßleitungen zur Registeraus¬ 
wahl beim FDC-Chip oder zur Command-Byte-Signalisierung am ACSI-Bus. 

Wie man sieht, wird durch den Zustand der R/W-Leitung am Eingang der DMA-Einheit 
entschieden, ob ein Zugriff auf das DMA-Mode-Register oder das DMA-Status-Register 
erfolgt. So kann das DMA-Status-Register nur ausgelesen und das DMA-Mode-Register nur 
beschrieben werden. Beide Register sind im Speicherraum des ST unter dergleichen Adresse 
zu finden! 

Durch das Bit 4 im DMA-Mode-Register läßt sich steuern, ob auf das Controller-Access- 
Register oder das Sector-Counter-Register zugegriffen werden soll. Diese beiden Register 
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können sowohl beschrieben als auch ausgelesen werden und belegen ebenfalls nur eine 
Adresse. 

Die einzelnen Register haben nun folgende Funktionen: 

DMA-Base- und Counter-Register 


Adresse 

Zugriff 

Funktion 

Label 

$FF 8609 

R/W 

High-Byte DMA-Base- und Counter-Register 

“dmahigh” 

$FF 860B 

RAV 

Mid-Byte DMA-Base- und Counter-Register 

“dmamid” 

$FF 860D 

RAV 

Low-Byte DMA-Base- und Counter-Register 

“dmalow” 


Diese drei jeweils 8 Bit breiten Register werden zu Beginn des Datentransfers mit der Start¬ 
adresse des zu übertragenden Datenbereichs geladen. (Wichtig! Reihenfolge des Zugriffs: 
Low-, Mid-, High-Byte!) 

Im DMA-Betrieb werden die Register von der DMA-Einheit nach jedem übertragenen 
Datenwort automatisch weitergezählt. Die drei Register bilden zusammen also einen Pointer 
auf das jeweils nächste zu übertragende Datenwort vom bzw. zum Hauptspeicher. 

Controller-Access-Register 


Adresse 

Zugriff 

Funktion 

Label 

$FF 8604 

RAV 

Durchgriff auf FDC-Register/ACSI-Bus 

“diskctl” 


Dieses Register ist nur zugänglich, wenn Bit 4 im DMA-Mode-Register “0” ist! Wenn man 
hier Daten einschreibt, werden diese von der DMA-Einheit an eines der FDC-Register 
weitergereicht oder auf den ACSI-Bus ausgegeben. Ein Lesezugriff auf diese Adresse ergibt 
den Inhalt eines der FDC-Register oder eines Bytes vom ACSI-Bus. 

Ein Durchgriff auf FDC-Register erfolgt, wenn Bit 3 im DMA-Mode-Register “0” ist. 
Welches FDC-Register man im Zugriff hat, legen dann Bit 1 und 2 im DMA-Mode-Register 
fest (diese steuern die “Adreßleitungen” CA 1 und CA2 für die FDC-Register). Das Controller- 
Access-Register hat zwar Wortbreite, für FDC-Register-Zugriffe sind jedoch nur die unteren 
8 Bit relevant (8-Bit-Bus zum FDC)! 

Für einen Zugriff auf den ACSI-Bus muß Bit 3 des DMA-Mode-Register gesetzt sein. Beim 
Durchgriff auf den ACSI-Bus ist auch hier wieder nur das niederwertige Byte des Registers 
“diskctl” relevant! 
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Sector-Counter-Register 


Adresse 

Zugriff 

Funktion 

Label 

$FF 8604 

R/W 

Zähler für Datenblöcke in Sektorgröße 

“diskctl” 


Über dieses Register wird der DMA-Einheit mitgeteilt, wie viele Blöcke (Sektoren) zu je 512 
Bytes vom bzw. zum FDC/ACSI-Bus übertragen werden sollen. Der Zugriff auf dieses Regi¬ 
ster ist nur möglich, wenn im DMA-Mode-Register das Bit 4 gesetzt ist! Da dieses Register 
nur 8 Bit breit ist, kann man in einem Rutsch nur 255 * 512 = 127,5 KBytes übertragen. 

Bei größeren Datenmengen muß man also mehrere “Pakete” direkt hintereinander versenden. 
Durch das Beschreiben dieses Registers wird der DMA-Vorgang intern schon gestartet. So 
wird die DMA-Einheit bei einem Schreibvorgang auf Floppy oder ACSI-Bus schon mal 
beginnen, den Fifo-Buffer aus dem Hauptspeicher mit Daten zu füllen. 

Wenn dann die DMA-Freigabe durch Löschen von Bit 7 im DMA-Mode-Register erfolgt, 
reagiert die DMA-Einheit auch auf Datenanforderungen vomFDC (FDRQ=Floppycontroller- 
Data-Request) oder ACSI-Bus (HDRQ = Harddiskcontroller-Data-Request). 


DMA-Status-Register 


Adresse 

Zugriff 

Funktion 

Label 

$FF 8606 

R 

Status der ausgeführten DMA-Operation 

“fifo” 


Nur die unteren 3 Bits dieses 16-Bit-Registers werden für Zustandsinformationen über eine 
DMA-Operation benutzt. 

Die Bits sindLow-aktiv, d. h., wenn der genannte Zustand aufgetreten ist, wird das Bit auf “0” 
zurückgesetzt! 


Bit 


Bedeutung 


0 Der “Turbolader” hatte eine Funktionsstörung. 

Es ist ein Fehler während der DMA-Operation aufgetreten. 

1 Das Sector-Counter-Register ist bis auf Null heruntergezählt. 

2 DATA REQUEST von FDC/ACSI-Bus ist inaktiv. 
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Die Bits 1 und 2 werden jedoch vom Betriebssystem nicht benutzt. Vor einem Zugriff auf das 
DMA-Status-Register sollte lt. ATARi-Information immer erst das Sector-Counter-Register 
selektiert werden (Bit 4 in DMA-Mode-Register setzen)! 

DMA-Mode-Register 


Adresse 

Zugriff 

Funktion 

Label 

SFF8606 

W 

“Kommando”-Register für die DMA-Einheit 

“fifo” 


Die Bedeutung der einzelnen Bits ist in Abbildung 1.14 erläutert. 
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DMfl-Mode Register 


Diese beiden Bits steuern die 
Leitungen CA1/CA2 der DMA-Ein- 
heit. Sie werden zur Register¬ 
auswahl bein FDC bzw. zur ACSI- 
Bus-Steuerung benötigt. 


Es erfolgt ein Zugriff auf 
eines der Peripherieregister: 


1 = 
0 = 


HUbi-Bus Kegisterzugr 
FDC-Begisterzugriff 




Bestimmt ob auf Sector Counter Reg. 
oder Controller Access Reg. zuge¬ 
griffen werden kann. 

1 = Sector Counter Register 
0= Controller Access Reg. 


DMA-interne Verwendung (=01 


DMA Mit FDC oder ACSI-Bus 

0 = DMA nit ACSI-Bus 
1 = DMA nit FDC 


DMA-Datentransportrichtung 

1 = DMA-Einh. schreibt an Peripherie 
0 = DMA-Einh. liest von Peripherie 


Abb. 1.14: Das DMA-Mode-Register 


Das Bit 8 (DMA-Datentransport-Richtung) hat noch eine besondere Funktion in Verbindung 
mit dem FIFO -Buffcr. Da der FIFO-Buffer nicht automatisch zu Beginn einer jeden neuen 
DMA-Operation gelöscht wird, hat der Programmierer selbst für “saubere” Verhältnisse zu 
sorgen. Durch “Klappern” (Wechseln des Zustands) mitBit 8 des DMA-Mode-Registers wird 
nämlich der Fifo-Buffer gelöscht und die DMA-Einheit auf einen DMA-Transfer vorbereitet! 
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Das Löschen des FIFO-Buffers wird sinnvollerweise gleichzeitig mit dem Einstellen der 
DMA-Datenübertragungs-Richtung durchgeführt. Beispiel: 

move.w #$090,dmajnode ; Diese Befehlssequenz löscht den 
move.w #$190,dmajnode ; FIFO-Buffer in der DMA-Einheit 

move.w #$090,dmajnode ; und schaltet diese auf Lesen 

(Bei Schreibzugriffen ist entsprechend gegensätzlich zu verfahren!) Soviel an dieser Stelle 
zur DMA-Einheit des ATARI ST. Weitere Informationen sind bei der Beschreibung des 
Floppy-Disk-Interface und des ACSI-Busses zu finden. 


Der Systembus des MEGA ST 

Erstmals bei den Geräten der MEGA ST-Serie hat ATARI die Möglichkeit vorgesehen, 
Erweiterungen des Systems vorzunehmen. So wurde im Gehäuse des MEGA ST Platz gelas¬ 
sen, um eine zusätzliche Erweiterungskarte unterzubringen. Die Karte wird liegend über die 
Hauptplatine (Mainboard) montiert (in der linken Gehäusehälfte). Dabei können zwei ver¬ 
schiedene Typen von Erweiterungskarten eingebaut werden. Die sogenannte “Half Card” hat 
die Abmessungen 137 x 145 mm, während die “Full Card” ca. 137 x 280 mm groß ist. 

In beiden Fällen ist an der Gehäuserückseite eine Befestigungsmöglichkeit für die Karten 
vorgesehen. Außerdem kann ein bereits vorbereiteter Ausschnitt der Gehäuserückwand ent¬ 
fernt werden, um so Platz für Anschlußbuchsen oder -kabel zu erhalten. 

Weitere Stabilität für die Erweiterungskarte ergibt sich durch die Befestigung der Karte mit 
Abstandshaltem im Gehäuseboden des MEGA ST. Entsprechende Aussparungen in der 
Hauptplatine des MEGA ST und Löcher zur Aufnahme der Befestigungsschrauben im Gehäu¬ 
seboden sind bereits vorgesehen. 

Die elektrische Verbindung erfolgtübereine64pol. Steckverbindung. An der Erweiterungskarte 
sitztauf der Lötseite eine zweireihige Federleiste (Buchse) nach DIN 41612, Bauform B. Auf 
dem Mainboard des MEGA ST befindet sich das Gegenstück dazu, eine zweireihige Messer¬ 
leiste. 


Pinbelegung des MEGA ST-Systembusanschlusses 

An den 64 Anschlüssen des Erweiterungsanschlusses stehen im Prinzip alle Signale der 
68000er-CPU zur Verfügung. D. h., daß sowohl der komplette Adreß- als auch der Datenbus 
und alle wesentlichen Steuer- und Meldeleitungen herausgeführt sind! 
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Die Einbindung des Systembusanschlusses (im folgenden kurz Megabus genannt) in die 
Hardware des MEGA ST zeigt der Schaltungsauszug in Abbildung 1.15. Alle Ausgangssignale 
sind ungepuffert und können einen LS-TTL-Eingang treiben. 

Das Signaltiming am Megabus ist das einer normalen 68000er-CPU mit einem Takt von 8 
MHz. Deshalb können periphere Einheiten auch ohne Probleme so angeschlossen werden, wie 
sie an eine normale 68000er-CPU angeschlossen würden. Natürlich kann die Logik auf der 
Erweiterungskarte auch die Bussteuerung übernehmen, wenn sie sich an das gleiche Protokoll 
hält, als wenn sie an eine 68000er-CPU angeschlossen würde. 

Dazu muß dem augenblicklich aktiven Busmaster (das ist die Einheit, welche gerade die 
Kontrolle über die Bussteuerung besitzt, also in der Regel die CPU) mit einem Low auf der 
BR-Leitung (BR = Bus-Request = Anfrage für Busübernahme) signalisiert werden, daß eine 
andere intelligente Einheit die Besteuerung übernehmen will. 



Abh, 1.15: Anschlußbelegung des Systembusses im MEGA ST 
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Der Busmaster gibt mit einem Low auf der BG-Leitung (Bus-Grant = Buszuteilung) an die 
anfragende Einheit sozusagen sein Einverständnis, daß nach Beendigung des gerade laufen¬ 
den Buszyklusses die Bussteuerung abgegeben wird. Jetzt wartet die anfragende Einheit, bis 
der laufende Buszyklus beendet ist (AS=Adress-Strobe gehtdann auf High, und DTACK muß 
ebenfalls auf High sein!), und übernimmt dann die Bussteuerung, indem sie als neuer Bus¬ 
master jetzt ein Low auf die BGACK-Leitung (Bus-Grant-Acknowledge = Quittung für Bus¬ 
zuteilung) legt und die BR-Leitung wieder auf High setzt. BGACK muß für mindestens einen 
Buszyklus des neuen Busmasters auf Low bleiben. Der neue Busmaster behält die Bussteue¬ 
rung so lange, wie er BGACK auf Low hält. 

Im MEGA ST sind bereits zwei Einheiten an der Arbeit (DMA-Baustein und BLITTER), 
welche ebenfalls von Zeit zu Zeit als Busmaster auftreten. Deshalb muß eine weitere Einheit, 
die in der Lage ist, die Bussteuerung zu übernehmen, sich den Bus mit den bereits vorhandenen 
Einheiten teilen. Dazu wird das Signal BGO (B us-Grant-Out) anPin21 des Megabusanschlusses 
benutzt. Das BGO-Signal am Megabus wird nicht direkt von der CPU, sondern vom GLUE 
erzeugt und berücksichtigt bereits die anderen DM A-Bausteine im Mega ST, die ebenfalls die 
Bussteuerung übernehmen können (Daisy-Chaining=Verkettung unter Berücksichtigung der 
Prioritäten von ST-DMA-Einheit, BLITTER und intelligenter Einheit am Megabus). 

Sind die Interrupts für die 68000er-CPU nicht gesperrt, sollte gewährleistet sein, daß ein 
anderer Busmaster als die CPU den Bus nicht länger als jeweils ca. 50 Buszyklen beansprucht, 
um noch eine einigermaßen niedrige Reaktionszeit auf Interruptanforderungen zu erhalten! 

Liegt die Bussteuerung bei der Erweiterung am Megabus, müssen die Buszyklen exakt wie 
die einer mit 8 MHz arbeitenden 68000er-CPU ausgeführt werden, da sonst Störungen mit dem 
Video-Controller auftreten können. Die Zugriffe des Video-Controllers auf das RAM müssen 
auch unter einem anderen Busmaster wie gewohnt ablaufen können. 

Nun noch eine kurze Beschreibung der einzelnen Anschlüsse des Megabusses: 

CLK 1:1 Rechteck-TTL-Taktsignal mit einer Frequenz von 8.0106 MHz. 

RESET, HALT Diese Anschlüsse dienen zur Initialisierung des Prozessors und des 

gesamten Systems. Die Anschlüsse sind bidirektional. RESET ist auf 
demMainboardmiteinem lK-Pullup-Widerstand abgeschlossen, HALT 
mit einem 4K7-Pullup-Widerstand. 

Führt die 68000er-CPU den Befehl RESET (CPU-Status und -Register bleiben unbeeinflußt) 
aus, wird die RESET-Leitung für ca. 15 pSek. (124 Taktzyklen) auf LOW gezogen und setzt 
damit externe Bausteine zurück. Kommt das RESET-Signal von einem anderen Baustein, so 
wird die CPU zurückgesetzt. 
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Die CPU zieht den HALT-Anschluß auf LOW, um damit auf ihren Funktionsstillstand 
hinzuweisen, den sie einnimmt, weil z. B. ein doppelter Busfehler aufgetreten ist. 

Wird der HALT-Anschluß von außen auf LOW gebracht, stellt die CPU am Ende eines laufen¬ 
den Buszyklus alle weiteren Tätigkeiten ein und versetzt alle Leitungen in den hochohmigen 
Zustand. 

Ein System-RESET erfolgt durch LOW-Setzen beider Leitungen RESET und HALT beim 
Einschalten oder durch Druck auf den RESET-Knopf. Der Einschaltreset oder der Druck auf 
den RESET-Knopf veranlaßt, daß beide Leitungen für ca. 130 msec auf LOW gezogen wer¬ 
den. 

Al - A23 Der 23-Bi£-Adreßbus direkt von der CPU. Auf dem Mainboard sind die 

Adreßleitungen mit 4K7-Pullup-Widerständen abgeschlossen. 

DO - D15 Der 16-Bit-Datenbus (bidirektional) der CPU. Auf dem Mainboard mit 

1 OK-Pullup-Widerständen abgeschlossen. 

FCO, FC1, FC2 Funktionscode-Leitungen von der CPU. Sie geben den Betriebszustand 

des Prozessors für den laufenden Buszyklus an. Abgeschlossen sind 
diese direkt von der CPU kommenden Leitungen auf dem Mainboard 
mit 1 OK-Pullup-Widerständen. 

AS Adress-Strobe. Bei LOW signaliert diese Leitung gültige Adreßinforma- 

tionen auf dem Adreßbus. 4k7-Pullup auf Mainboard! 

RAV ReadAVrite-Leitung. LOW zeigt einen Schreibzyklus, HIGH einen 

Lesezyklus an. 4k7-Pullup auf Mainboard! 

UDS.LDS Upper-Data-Strobe, Lower-Data-Strobe. LOW an UDS signalisiert 

gültige Informationen auf dem höherwertigen Byte des Datenbusses. 
LOW an LDS zeigt gültige Daten auf dem niederwertigen Byte des 
Datenbusses an. Bei einem Wortzugriff sind beide Leitungen auf LOW. 
Beide Leitungen sind mit4k7-Pullups auf dem Mainboard abgeschlos¬ 
sen! 

Data-lransfer-ACKnowledge. Bidirektionaler Anschluß (Open Collec- 
tor). Mit einem LOW wird einDatentransfer bestätigt. Ein Erweiterungs¬ 
baustein, dem Daten von der CPU zugeschrieben werden, muß der CPU 
den Empfang der Daten mit einem LOW auf dieser Leitung bestätigen. 


DTACK 
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BERR 


E 


VPA 


VMA 


BR 


BGO 


Ist die periphere Einheit auf der Erweiterungskarte Busmaster, so muß diese 
an der DTACK-Leitung “lauschen”, ob der DatenaustauschkoiTekt abgelau¬ 
fen ist. Mit einem lK-Pullup-Widerstand ist diese Leitung auf dem Main¬ 
board abgeschlossen. 

Bus Error. Zeigt der CPU oder einer DMA-Einheit an, das keine periphere 
Einheit auf den laufenden Buszyklus reagiert hat. Beim ST wird automa¬ 
tisch nach 64 Taktzyklen diese Leitung auf LOW gesetzt, wenn bis dahin 
keine Reaktion von einem angesprochenen Peripheriebaustein erfolgt ist. 
Diese Open-Collector-Leitung der CPU ist mit einem 4K7-Pullup-Wider¬ 
stand auf dem Mainboard abgeschlossen. 

Enable Clock. Dient zur Synchronisation beim Anschluß von Peripheriebau¬ 
steinen der 6800-Serie. Dieser Takt ist mit dem 8 MHz-Taktfest verknüpft. 
Für sechs Taktzyklen des CLK-Signals ist E auf LOW, dann wieder auf 
HIGH für vier Taktzyklen (also ein Takt von ca. 0,8 MHz). 

Valid Peripheral Address. Der CPU wird mit einem LOW über diese Lei¬ 
tung mitgeteilt, das ein synchron arbeitender Baustein (z. B. Peripheriebau¬ 
stein der 68XX-Serie) adressiert wurde. Abschluß mit 2K2-Pullup-Wider- 
stand auf dem Mainboard. 

Valid Memory Address. Die CPU reagiert damit auf die Anforderung 
(durch LOW an VPA) nach einem synchronen Buszyklus und meldet mit 
einem LOW über VMA, daß sie nun auf den E-Takt synchronisiert ist. 4K7- 
Pullup auf Mainboard! 

Bus Request. Mit einem LOW wird der CPU hier mitgeteilt, daß ein anderer 
Baustein die B ussteuerung übernehmen möchte. Auf dem Mainboard ist die 
Leitung mit einem 4K7-Pullup-Widerstand abgeschlossen. ATARI emp- 
fiehltebenfallseinen4K7-Pullup-AbschlußwiderstandaufderErweitErungs- 
karte. 

Bus Grant Out. Der Einheit auf der Erweiterungskarte, welche die Bussteue¬ 
rung angefordert hat (mit LOW auf der BR-Leitung) wird mit einem LOW 
signalisiert, daß sie die Bussteuerung nach Abschluß des laufenden Buszy- 
klusses übernehmen kann. 

Dieses Signal wird vom GLUE geliefert und ist mit den anderen Bausteinen 
des Mega ST (BUTTER und DMA-Einheit), die ebenfalls die Bussteue¬ 
rung von Zeit zu Zeit übernehmen können, “abgestimmt”. 
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BGACK Bus Grant ACKnowledge. Mit einem LOW auf dieser Leitung bestätigt 

der anfordemde Baustein, daß er die Bussteuerung übernommen hat 
(Buszuteilungsquittung). 

Als Open-Collector-Leitung ist dieser Anschluß auf dem Mainboard mit 
einem 4K7-Pullup-Widerstand abgeschlossen, was ATARI auch für den 
Abschluß auf der Erweiterungskarte empfiehlt. 

NMI, INT 5, INT 3 Je nachdem, welche dieser drei Leitungen von der Logik der Erweiterungs- 
karte auf LOW gezogen wird, wird ein Interrupt der Priorität 7 (Non 
Maskable Interrupt), Priorität 5 oder Priorität 3 ausgelöst. Sollten alle 
drei Interrupts gleichzeitig auftreten, wird natürlich der höchstwertige 
(Priorität 7) zuerst berücksichtigt. Die periphere Einheit am Megabus 
muß nun korrekt auf die Interruptbestätigung durch die 68000er-CPU 
reagieren (siehe auch Teil II, Kapitel 4, Abschnitt “Interrupt-Steue¬ 
rung”). 


Stromversorgung der Erweiterungskarte 

Die Stromversorgung der Erweiterungskarte erfolgt über eine 6pol. Steckverbindung (siehe 
Abbildung 1.15). Die +5V können dabei mit bis zu 750 mA und die +12V mit bis zu 500 mA 
belastet werden. 


Speicherraumreservierungen für die Erweiterungskarte 

Nach ATARI-Informationen können der Adreßbereich von $C0 0000... $CF FFFF, $FF 0000 
... $FF 7FFF und $FF FE00... $FF FFFD durch die Erweiterungskarte belegt werden. Für die 
Benutzung aller weiteren Adreßbereiche behält sich ATARI das Recht auf eine eigene Benut¬ 
zung vor. 

Da für den Megabus inzwischen einige Erweiterungen erhältlich sind, wie z. B. eine Floating- 
Point-Coprocessor-Karte von ATARI, Einbau-Festplatten mit Controller, Netzwerkkarten 
und Ansteuerkarten für Großbildschirme, ist der eine oder andere Besitzer eines “kleinen” STs 
(260ST/520ST+ oder 520ST(M)) nicht abgeneigt, seinem System ebenfalls einen Megabus- 
Anschluß zu spendieren. 

Im ST Magazin, Ausgabe 10/88, ist aufgezeigt, wie unerschrockene Hardware-Bastler ihren 
“kleinen” ST mit einem Megabus-Anschluß nachrüsten können! 
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Kapitel 2: Das Grafiksystem 

Die Computer der ATARI ST-Serie kennen vom Prinzip her zwei Grafikbetriebsarten: 

- Monochrombetrieb 

- Colorbetrieb 


Nur schwarz/weiß, aber gestochen scharf - 
Der Monochrombetrieb 

Der Monochrombetrieb eignet sich durch seine hohe Graftkauflösung von 640 * 400 Punkten 
und der schwarz-auf-weiß Darstellung hervorragend für die Textverarbeitung und den Pro¬ 
grammierbetrieb. Der von ATARI für den Monochrombetrieb vorgesehene Monitor SM124 
/ SM125 liefert ein scharfes und flimmerfreies Bild. 

Das wird durch eine Bildwiederholfrequenz von ca. 70 Hz erreicht, während diese bei 
normalen Fernsehern und Monitoren üblicherweise bei 50 Hz (50 Haibbilder/s.) liegt. Der ST 
stellt70Vollbilder/smit400 sichtbaren Bildschirmzeilen dar. Dazu muß dieHorizontalfrequenz 
(Zahl der Bildschirmzeilen/s) auf einen Wert von ca. 36 kHz gebracht werden. Der ST arbeitet 


Honitorbuchse des Atari ST 



Außenansicht auf die Buchse 


1 - Audio Ausgang 

2 - H+V-Synch.-Signalgemisch 
Z - Port A; Bit 6, Soundchip 

4 - Monochrom-Sensor 

5 - Audio Eingang 

6 - Grün-Signal 

7 - Rot-Signal 

8 - +12U out (max, 10mA) 

9 - Horizontal-Synch.-Signal 

10 - Blau-Signal 

11 - Honochromsignal 

12 - Vertikal-Synch,-Signal 

13 - Masse 


Abb. 2.1: Die Monitorbuchse des ATARI ST 
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mit einer H-Ablenkfrequenz, die also nahezu 2,5mal so hoch wie bei “normalen” Fernsehern 
und Monitoren (ca, 15,6 kHz) liegt. Ein “normaler” Monitor oder Fernseher mit Videoeingang 
ist da klar überfordert und kann evtl. Schaden erleiden, da die Hochspannungserzeugung in 
Fernsehern und Monitoren üblicherweise vom Horizontaloszillator gesteuert wird. 

Angeschlossen wird der ATARI-Monochrommonitor an die 13polige Monitorbuchse des ST. 

Die Bildinformation wird dem Monitor bei Monochrombetrieb über den Anschlußpin 11 
(Monochrom-Signal) der Monitorbuchse angeboten. Das Signal kennt, ähnlich dem Ausgang 
eines Digitalbausteins, nur zwei Zustände. Der ST liefert ein Signal von 1 Vss an 75 Ohm. 



Vertikal-Sunch.-Signal 

3.5 V -I-11- 


0U 


Horizontal-Sunch.-Signal 



Abb. 2.2: Die Video-Ausgangssignale bei Monochrombetrieb 
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Ein Spannungs wert von+1V gegen Masse (liegt an Pin 13 der Monitorbuchse) entspricht dabei 
der Bildinformation “weiß”, undOV bedeutet somit “schwarz”. Zwischenwerte (Grauabstufun¬ 
gen) sind nicht möglich. 

Die Synchronisationssignale für das entsprechende Strahlriicklauf-Timing im Monitor wer¬ 
den für Horizontal- und Vertikalablenkung sowohl getrennt als auch in Form eines Signal- 
gemischs an der Monitorbuchse angeboten. Sie haben TTL-Pegel und sind Low-aktiv, was 
bedeutet, daß die Aktion (Elektronenstrahlrücklauf im Monitor zum Zeilen-/Bild-Anfang) 
ausgelöst wird, wenn das Signal auf Low-Pegel geht. 


Der Monitor bestimmt die Betriebsart 

Über Pin 4 der Monitorbuchse “erfühlt” der ST, welche Art von Monitor angeschlossen ist. 
Durch einen Low-Pegel wird “mitgeteilt”, daß im hochauflösenden Monochrom-Modus gear¬ 
beitet werden soll. Der Anschluß führt im ST auf den I/O-Port, Bit 7, des Multi-Function-Peri- 
pheral-Bausteins (MFP) 68901. 

Bei der Systeminitialisierung wird durch Abfrage des eben erwähnten Port-Anschlusses 7 des 
MFP festgestellt, ob im Monochrom- oder Colorbetrieb gearbeitet wird. 

Ein Pegelwechsel an diesem Eingang, z. B. durch Abziehen des Monitorsteckers, wird wäh¬ 
rend des Vertikal-Blank-Interrupts festgestellt und führt zur Neuinitialisierung des Systems. 


Jetzt wird’s bunt - Die Colorbetriebsart 

Im Colorbetrieb arbeitet der ST mit “normalen” RGB-Monitoren oder Farbfernsehern mit 
SCART-Eingang zusammen. 

Hierbei wird die Farbinformation für jeden Bildpunkt in entsprechende Intensitätswerte der 
drei Primärfarben Rot, Grün und Blau zerlegt. Für jede Primärfarbe wird die Bildinformation 
über eine eigene Leitung dem Monitor/Femseher zugeführt. 

Der ST liefert RGB-Signale von max. 1 Vss an 75 Ohm, denen ein Gleichspannungspegel von 
ca. 0,5 Volt unterlegt ist, wobei ein Spannungswert von +1,5 Volt gegen Masse der höchsten 
Farbintensität entspricht. Ein Wert von 0,5 Volt (- unterlegter Gleichspannungspegel) 
bedeutet somit niedrigste Farbintensität, 

Die Synchronisationssignale sind auch in dieser Betriebsart wieder getrennt von den Signalen 
für die Bildinformation geführt. Sie stehen sowohl getrennt nach H- und V-Signal als auch als 
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Abb. 2.3: Anschluß des ST an einen Farbfernseher mit SCART-Eingang 


Synchronsignalgemisch an Pin 2 der Monitorbuchse zur Verfügung. (Achtung! Das Synchron¬ 
signalgemisch steht wegen des eingebauten Modulators bei älteren 520STM-Geräten nicht zur 
Verfügung!) 

Durch die getrennte Zuführung von Rot-, Grün- und Blau-Signalen erhält man auch auf einem 
handelsüblichen Farbfernseher mit SCART-Eingangsbuchse ein besseres Farbbild als von 
Computern mit einem sogenanntem FBAS-Ausgang. 

Ein Farb-Bild-Austast und Synchronsignal-Ausgang (FBAS-Ausgang) hat zwar den Vorteil,, 
daß man nur eine Leitung (nun ja, die Masseleitung ist natürlich ebenfalls noch erforderlich) 
zwischen Computer und Monitor benötigt. 

Alle Informationen wie Farbe, Farbintensität, Synchronisier- und Austastinfonnation (zur 
Dunkeltastung des Elektronenstrahls in der Bildröhre, während dieser vom Ende einer Bild¬ 
schirmzeile zurück zum Anfang einer neuen Zeile springt) sind in einem Signal gewisserma¬ 
ßen verschlüsselt enthalten. 
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Rot-Signal 

Grün-Signal 

Blau-Signal 


3.5U 

0U 








Jl b. 






Vertikal- 
Synch,“Signal 



Horizontal- 
Synch.-Signal 


H+y-Synch.- 

Signalgenisch 


Ahb. 2.4: Die Video-Ausgangssignale bei RGB-Betrieb 


Sie müssen jedoch (aha! Jetzt kommt der Haken!) im Monitor erst wieder entschlüsselt wer¬ 
den. Dabei erleidet die eigentliche Bildinformation einige Qualitätseinbußen durch Dekodier- 
und Verzögerungsschaltungen. 


Das bessere Farbbild - mit RGB-Monitor 

Bei einem RGB-Anschluß werden die Bildinformationen dagegen schon direkt in ihre 
Primärfarben zerlegt angeboten, wie es der Monitor/Femseher im Endeffekt ja eigentlich 
benötigt. Diese Signale erfahren im Monitor/Femseher nur noch eine Pegelanpassung und 
gelangen dann direkt an die Bildröhre, welche für jede Primärfarbe ein eigenes 
Strahlerzeugungssystem besitzt. Die RGB-Bildinformation wird also kaum beeinflußt und 
verfälscht. 

Man kann übrigens mit relativ geringem Aufwand einen handelsüblichen Monochrom-Moni¬ 
tor dazu “bewegen”, als Sichtgerät für den Colorbetrieb zu arbeiten. Die einzelnen Färb- 
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Abb. 2.5: So einfach läßt sich ein normaler Monochrom-Monitor als Sichtgerät für die Colorbe- 
triebsart des ST anschalten 


informationen und Farbintensitätswerte müssen nur in entsprechende Grauwerte umgesetzt 
werden. 

Außer den Anschlußelementen an Computer und Monochrom-Monitor sowie Koaxialkabel 
entsprechender Länge benötigt man nur noch vierWiders tände, einenLötkolben, Seitenschnei¬ 
der und ein wenig bastierisches Geschick. 

Soviel zur Video-Anschlußtec hn ik bei den ST-Computem. Erwähnt sei hier noch, daß der 
ATARI 520ST(F)M/1040STFM mit einem eingebauten Modulator ausgerüstet ist. Damit ist 
es möglich, einen Farbfernseher als Sichtgerät für Colorbetrieb zu benutzen. Aufgrund der 
hierbei auftretenden Qualitätsverluste des Bildinformationssignals durch Modulation im ST 
und Demodulation im Farbfernseher ist die Bildqualität natürlich nicht mit der eines RGB- 
Monitors zu vergleichen. Ein längeres Arbeiten mit einem über den Modulator angeschlos¬ 
senen Farbfernseher ist insbesondere bei Textdarstellung nicht empfehlenswert. 


Organisation des Bildschirmspeichers 

Die Computer der ST-Serie besitzen keinen separaten Bildschirmspeicher wie z. B. viele “pro¬ 
fessionelle” Personal-Computer. 

Vielmehr wird ein Teil des normalen RAMs dafür benutzt. Im Prinzip ist die Lage des 
Bildschirm-RAMs im Speicherraum des ST beliebig einstellbar, also nicht auf einen bestimm¬ 
ten Adreßbereich beschränkt. 
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Der Video-Hardware muß nur “gesagt” werden, ab welcher Adresse im RAM der Bildschirm- 
speicher beginnt. Dann werden die ab dieser Adresse folgenden 32000 Bytes im RAM vom 
Video-Controller als Bildschirminformation interpretiert und entsprechend umgesetzt. 

Je nach Wahl der gewünschten Bildschirmauflösung werden die Daten im Bildschirmspeicher 
vom Video-Controller in ein Videosignal umgewandelt. 


High resolution - Hohe Auflösung 

Diese Darstellungsart ist nur in Verbindung mit dem hochauflösenden Monitor möglich. Es 
werden 640Bildpunkte in400Zeilen und dabei mitzwei Farben dargestellt. Ein Bildschirmpunkt 
(Pixel = umgangssprachliche Kurzform von Picture cell = zu deutsch: Bildelement) kann 
hierbei nur zwei Zustände annehmen, entweder hell oder dunkel. Entsprechend der Abbildung 
2.6 wird jedes helle Pixel durch ein gelöschtes Bit und ein dunkles Pixel durch ein gesetztes 
Bit im Bildschirmspeicher dargestellt. 



Abb. 2.6: Organisation des Bildschirmspeichers für die High-Resolution-Darstellung 


Medium resolution - Mittlere Auflösung 

Auf dem hochauflösenden Monitor ist diese Darstellungsart nicht möglich (zumindest nicht 
ohne kräftige bastierische Klimmzüge wie z. B. in der “ST COMPUTER” 5/88 beschrieben). 
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Es handelt sich hierbei um eine Colorbetriebsart, die einen RGB-Monitor/Farbfemseher mit 
SCART-Eingang oder einen “normalen” Monochrommonitor/Femseher mit entsprechendem 
Anschlußkabel erfordert. Die Bildschirmdarstellung umfaßt hierbei 200 Zeilen zu je 640 
Pixel. Jedes Pixel kann hierbei vier Zustände, also vier Farben annehmen. 

Der Bildschirmspeicher wird vom Video-Controller dabei als zwei sogenannte Bit-Planes 
(Bit-Ebenen) interpretiert, wobei die Kombination der jeweils “übereinanderliegenden” Bits 
der beiden Planes bestimmt, welche Farbe der zugehörige Bildschirmpunkt auf dem Monitor 
dann bekommen soll (siehe Darstellung in der Abbildung 2.7). 



Abb. 2.7: Organisation des Bildschirmspeichers für die Medium-Resolution-Darstelhmg 


Low resolution - Niedrige Auflösung 

Auch hierbei handelt es sich um eine Colorbetriebsart. Es werden 320 Pixel in 200 Zeilen auf 
dem Bildschirm dargestellt. 

Der Bildschirmspeicher wird jetzt in vier B it-Planes organisiert. Ein Pixel wird also durch vier 
Bits beschrieben. Somit kann die Pixelfarbe aus einem der 16 zur Verfügung stehenden Farb- 
register ausgewählt werden. 
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Ahb. 2.8: Organisation des Bildschinnspeiehers bei Low-Resolution 

Indirekte Farbgebung 

ATARI benutzt auch hier, wie schon bei den 8-Bit-Modellen 800XL/130XE, das Prinzip der 
Color indirection, d. h., die Bitkombination für ein Pixel legt noch nicht direkt eine bestimmte 
Farbe für den Bildschirmpunkt fest, sondern dient dem Video-Controller lediglich zur Aus¬ 
wahl eines Farbregisters. Dieses Farbregister enthält dann erst den entsprechenden Farbwert 
für das Pixel. Der ST besitzt insgesamt 16 solcher Farbregister, auch Palette-Register genannt, 
die mit unterschiedlichen Farbinformationen geladen werden können. Pro Pixel stehen bei 
Medium Resolution also zwei Bits zur Verfügung, die entsprechend ihrer Wertigkeit im 
Video-Controller eines von vier Palette-Registern 0...3 adressieren können, ln Low Resolu¬ 
tion kann mit vier Bits pro Pixel eines von 16 Farbregistem angewählt werden. 


Der ATARI-Videocontroller 

ATARI verwendet auch in den 16 Bit-Computern der ST-Serie keinen Standard-Video- 
Controller. Es handelt sich hierbei um eine Eigenentwicklung mit speziell auf den ST hin 
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ausgelegten Eigenschaften. Der Video-Controller läßt sich ebensowenig wie die anderen 
Systemkomponenten DMA-Einheit, Speicherverwaltung usw. in einem ganz bestimmten 
Chip auf der Platine des ST wiederfinden. Vielmehr bilden erst die Kombination von CPU und 
vier ATARI-spezifischen Chips, nämlich MMU, DMA, Shifter und GLUE, ein funktionsfä¬ 
higes System. 

Wenn also hier von dem ST-Video-Controller die Rede ist, so sind damit alle Register und 
Steuereinheiten in den vier ATARI Custom-Chips gemeint, die zusammen die Funktion des 
Video-Controllers erfüllen! Wesentliche Aufgaben bei der Erzeugung des Videosignals über¬ 
nimmt hierbei der Shifter-Chip. 

Für den Programmierer - auch den hardwarenahen Systemprogrammierer - ist es jedoch 
letztlich egal, in welchem Chip sich welches Register befindet (Hauptsache, die Adresse ist 
bekannt). Die Arbeitsweise des Video-Controllers soll das in Abbildung 2.9 aufgeführte 
Prinzipschaltbild verdeutlichen. 


So werden Bits zu Pixel 

Die Schieberegister im Video-Controller haben Wortbreite und werden zyklisch mit den 
Daten aus dem Bildschirmspeicher geladen. CPU-Zugriffe und Zugriffe des Videocontrollers 
(Shifters) sind dabei zeitlich ineinander verzahnt. Die Information wird dann bitweise im 
Pixel-Takt an die Register-Select-Logik “hinausgeschoben”. Diese bestimmt aufgrund der 
Ausgangsbitkombination der Schieberegister und der eingestellten Grafikbetriebsart im Shift- 
Mode-Register das für das Pixel maßgebende Farbregister. 

Die Grafikbetriebsart wird mit dem Shift-Mode-Register nach dem in Abbildung 2.10 
dargestellten Schema eingestellt. Ist von der Register-Select-Logik das Farbregister ausge¬ 
wählt worden, wird aus diesem die Information für Farbe und Farbintensität an das Output- 
Register ausgegeben. Die Farbintensität, mit der jede der drei Primärfarben im Ausgangssignal 
vertreten ist, ist in acht Stufen einstellbar. Für jede Farbe existieren drei digitale Ausgangsan¬ 
schlüsse, also sind 2 3 = 8 Kombinationen = Farbintensitäten möglich. So läßt sich durch ent¬ 
sprechende Bitkombination in jedem Farbregister einer von 2 (3+3+3) = 2 9 = 512 Farbtönen 
anwählen. 

Die Information aus dem für den Bildpunkt angewählten Farbregister gelangt also ins Output- 
Register und wird an dessen Ausgängen mit einem aus jeweils drei Widerständen gebildeten 
Digital/Analog-Wandler in eine analoge Spannung umgesetzt. 

Dazu wird noch das Blanking-Signal gemischt, und dann geht es über Impedanzwandler ab 
an die Monitorbuchse des ST. 
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Ahb, 2.9: Primipschaltbild des ST-Video-Controllers 


In der Monochrom-Betriebsart kann lediglich über das niedrigstwertige Bit des Farbregisters 
0 eingestellt werden, ob derBildpunkt normal oder invertiert ausgegeben werden soll, was eine 
“normale” oder “invertierte” Bildschirmdarstellung zur Folge hat. 

Für einen reibungslosen Ablauf dieser Vorgänge sorgt die Timing-Logik, welche aus dem 32- 
MHz-Takt des ST-Systems alle für den Video-Controller erforderlichen Timing-Signale ge¬ 
neriert. Der 32-MHz-Mastertakt gelangt vom Oszillator in den Shifter und wird dort zur Pixel- 
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Abb. 2.10: Das Shift-Mode-Register 


Färb-Register 


XlXlXlXIXI 1 

8 7 

TTxTT 

T 1X1 1 1° 

i 

nicht 

benutzt 

r 

~ 1 ' 1_ 
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Abb. 2.11: Die Färbt egister 


ausgabe benutzt. Ein aus den 32 MHz im Shifter abgeleiteter 16-MHz-Takt wird zur MMU 
geführt, die daraus Horizontal- und Vertikal-Synchronimpulse erzeugt und außerdem den 8- 
MHz-Takt für u. a. die CPU erzeugt. 
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Abb. 2.12: Die Bitbelegung des Sync-Mode-Registers 


Mit dem Sync-Mode-Register läßt sich unter anderem einstellen, mit welcher Vertikal- 
Synchronisationsfrequenz gearbeitet wird. Das Bit 0 verdient dabei noch besondere Beach¬ 
tung. Ist es gelöscht, werden die Impulse für die Horizontal- und Vertikalsynchronisation von 
der Timing-Logik des Video-Controllers selbst erzeugt. Bei gesetztem Bit 0 erwartet die Tim¬ 
ing-Logik jedoch die H- und V-Synch.-Impulse (Low-aktiv) von einer externen Signalquelle. 
Eingespeist werden diese an den H- und V-Sync.-Anschlüssen der Monitorbuchse. DieH- und 
V-Sync.-Anschlüsse des ST-Video-Controllers sind dann als Eingänge geschaltet! 

So ließe sich der ST also mit externen Videosignalquellen wie z. B. Videokamera oder Video¬ 
recorder synchronisieren. Leider ist damit noch keine pixelgenaue Synchronisation möglich, 
und es kommt zu unschönem “Zeilenreißen”. Von einer Zeile zur nächsten ergeben sich 
Sprünge und somit ein verzerrtes Mischbild. Um diese Verzerrungen auszumerzen, muß man 
(im STE endlich realisiert) den gesamten ST mit einem externen Takt versorgen. 

Der Video-Controller ist im Prinzip ein System mit “Eigenleben”, das sowohl Zugriff auf den 
Adreß- als auch den Datenbus (nur der RAMs!) hat, ohne den Umweg über CPU-Register 
nehmen zu müssen. Einige Daten muß die CPU dem Video-Controller aber schon mitteilen, 
damit dieser z.B. weiß, wo die Bildschirmdaten im Speicher stehen. Den Anfang des Bild¬ 
schirmspeichers erfährt der Video-Controller aus dem 

Video-Base-Register 


Adresse 

Zugriff 

Funktion 

Label 

$FF 8201 

RAV 

Video-Base-Register High-Byte 

“dbaseh” 

$FF 8203 

RAV 

Video-Base-Register Mid-Byte 

“dbasel” 
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Das Video-Base-Register besteht eigentlich aus zwei einzelnen Registern zu je acht Bit, 
beginnt an einer ungeraden Adresse und ka nn deshalb nicht mit einem Word-Zugriff 
angesprochen werden. Der Anfang des Bildschirmspeichers kann im Hauptspeicher des ST 
auch immer nur an einer 256-By te Schwelle (an einer Page-Grenze) liegen, da ja für das Low- 
Byte der vollständigen Adresse das Register fehlt. Ein Zugriff auf das Register ist nur im 
Supervisor-Modus möglich! 

Das folgende Register dient dem Video-Controller als Adreßzähler für denBildschirmspeicher. 
Die CPU kann den Inhalt des Video-Adress-Counters nur auslesen (Supervisor-Mode!). 

Video-Adress-Counter 


Adresse 

Zugriff 

Funktion 

Label 

$FF 8205 

R 

Video-Adress-Counter High-Byte 

“vcounthi” 

$FF 8207 

R 

Video-Adress-Counter Mid-Byte 

“vcountmid” 

$FF 8209 

R 

Video-Adress-Counter Low-Byte 

“vcountlow” 


Gesetzt wird der Video-Adress-Counter über das Video-Base-Register. Dieser Counter 
übernimmt zu Beginn eines jeden Bildes die Anfangsadresse des Bildschirmspeichers aus dem 
Video-Base-Register. 


Erwünschte Unterbrechungen? 

Die H- und V-Synchronisationssignale vom Video-Controller werden zusätzlich im ST noch 
zur Interruptsteuerung benutzt. Der Vertical-Blank-Interrupt wird ausgelöst, sobald die letzte 
Bildschirmzeile eines Bildes geschrieben ist. Im Monitor muß der Elektronenstrahl, der die 
Pixel auf der Phosphorschicht des Bildschirms zum Leuchten bringt, ausgeschaltet werden. 
So wird verhindert, daß derBetrachter sieht, wie der Elektronenstrahl vom Strahl-Ablenksystem 
wieder an den Anfang der ersten Bildschirmzeile des neuen Bildes positioniert wird (also von 
rechts unten nach links oben springt). 

Während dieser Zeitspanne lassen sich einige Programmroutinen abwickeln, die zyklisch 
irgendwelche Aktionen durchführen. So wird z. B. im Vertical-Blank abgefragt, ob bei den 
Floppys der Motor noch läuft. Steht dieser, wird die entsprechende Floppy deselektiert. Vom 
Betriebssystem ist die Möglichkeit für den Programmierer vorgesehen, eigene VBlank- 
Interruptroutinen einzufügen (siehe auch Teil I, Kapitel 1, “Der Vertical Blank Händler”). 

Es ist möglich, auch beim Strahlrücklauf vom Ende einer Bildschirmzeile zum Anfang einer 
neuen Bildschirmzeile (Horizontal-Blanking = Horizontal-Strahlaustastung) einen Interrupt 
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auszulösen. Im normal arbeitenden ST-System ist dieser HBlank-Interrupt jedoch nicht 
vorgesehen. Ein laufender Prozeß würde nämlich in der Monochrom-Betriebsart sonst alle 28 
pSek für mindestens sieben pSek unterbrochen. Solange dauert es nämlich, bis der Prozes¬ 
sor den Interrupt erkannt, quittiert und abgeschlossen hat. Dazu kommt natürlich noch die Zeit 
für die eigentliche Interrupt-Routine, die ausgeführt werden soll. Der HBlank-Interrupt würde 
somit schon mindestens 25% der Prozessorzeit beanspruchen; ein schöner Bremsklotz also. 


Jede Menge Manipulationen möglich 

Die Programmierung des ST-Video-Controllers wird dem Programmierer durch eine Reihe 
von XBIOS-Aufrufen erleichtert. Es sind dies die XBIOS-Funktionen #2 (“Physbase”), #3 
(“Logbase”), #4 (“Getrez”), #5 (“Setscreen”), #6 (“Setpallette”), #7 (“Setcolor”) und #37 
(“Vsync”). Nähere Einzelheiten dazu im Teil I, Kapitel 1, in der “XBIOS-Referenz”. 

Die komfortablen Möglichkeiten des ST, Text und Grafiken gleichermaßen gut darzustellen, 
liegen darin begründet, daß es keinen speziellen Character- und Grafik-Modus gibt. 

In herkömmlichen Systemen hat man üblicherweise einen sogenannten Charactergenerator 
(Zeichengenerator), der in Zusammenarbeit mit einem Video-Controller die Darstellung von 
Textzeichen auf dem Bildschirm ermöglicht. Die Zeichen können so nur in einem relativ gro¬ 
ben Raster auf dem Bildschirm angeordnet werden (Zeichenmodus). Ein zusätzlicher Grafik¬ 
modus ermöglich das Setzen und Rücksetzen von einzelnen Bildpunkten. 

Beim ST gibt es nur den Grafikmodus. Alle Zeichen und Buchstaben werden durch einzelnes 
Setzen und Rücksetzen von Pixeln gebildet. Das beansprucht natürlich einiges an Prozessorzeit 
und Speicherplatz, gestattet dafür aber das komfortable Mischen von Grafik und Text, da 
Textzeichen für den ST nichts anderes als Gruppen von Grafikpunkten darstellen. Außerdem 
lassen sich so Zeichen im Pixelraster beliebig auf dem Bildschirm plazieren (z. B. Textverarbei¬ 
tung “Signum!”). Proportionalschrift ist somit auch möglich! 


Der Blitter 

Zur Entlastung der CPU und Beschleunigung der Graphikausgabe wurde von ATARI schon 
bei der Entwicklung der ST-Computerserie ein Hilfsbaustein vorgesehen, der wesentliche 
Aufgaben bei der Aktualisierung des Bildschiimspeichers übernehmen sollte. Zunächst wur¬ 
den die Geräte der MEGA ST-Serie mit dem Bit-Block-Transfer-Processor (Blitter) ausgestat¬ 
tet. Der Blitter übernimmt dabei die Aufgaben, welche bisher von der BitBlt-Funktion der 
Line-A-Routine #$A007 ausgeführt wurden. Es handelt sich hierbei also um eine hardware¬ 
mäßige Realisierung des BitBlt-Algorithmus. 
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Bei einem Bit-Block-Transfer können Bitfelder-Daten von einer Ausgangsposition im 
Bildschirmspeicher an eine Zielposition übertragen werden. 

Dabei ist es möglich, die Ursprungsdaten über eine wählbare logische Verknüpfung mit dem 
bereits im Zielspeicherbereich vorhandenen Bitmuster zu verküpfen. Es ist aber ebenfalls 
möglich, einen Zielbereich mit einem vorher definiertem Muster zu füllen und so beispiels¬ 
weise Bildschirmausschnitte zu löschen oder vorzubesetzen. 

Unter Zuhilfenahme der BitBlt-Funktiön lassen sich so relativ einfach Funktionen wie Text- 
Scrolling, Textumsetzungen in Fettschrift, Italic oder Outline realisieren. Funktionen wie 
Window-Updating und -Verschiebung profitieren ebenfalls von den Möglichkeiten, welche 
die BitBlt-Funktion bietet. 


Der Atari ST-Blitter 

Der Grundalgorithmus der BitBlt-Funktion wurde erstmalig durch Newman & Sproull im 
Jahre 1979 bei der Beschreibung der RasterOp-Funktion, im Buch “Principles of interactive 
Computer graphics” definiert. Diese Definition sah einen “Bit für Bit”-Block-Transfer vor. Es 
waren nur wenige logische Verknüpfungsmöglichkeiten zwischen Quell- und Zielbitfeldern 
vorgesehen. 

Im Laufe der Zeit wurden die Grundfunktionen um weitere Verknüpfungsmöglichkeiten 
erweitert und die Parallelverarbeitung von Bits implementiert. 

Außerdem wurde vorgesehen, die Ursprungsdaten mit einem frei definierbaren Grundmuster 
“vorzuverarbeiten" (sogen. Halftone Pattern) und erst das daraus entstehende Ergebnis mit 
den Zieldaten zu verknüpfen. Ein nach diesen Definitionen erstellter RasterOp-Chip (die 
“VL16160 RasterOp Graphics/Boolean Operation ALU" von VLSI-Technology) konnte je¬ 
doch immer nur Einzeldaten bearbeiten. Die Quell-, Halftone- und Zieldaten mußten laufend 
von der CPU in den RasterOp-Chip nachgeladen werden. DMA-Betrieb war nicht möglich. 

Der ATARI ST-Blitter ist ein eigenständiger Prozessor, der alle Definitionen der BitBlt- 
Funktion erfüllt. Er verarbeitet die Daten wortweise (also maximal 16 Bits auf einmal) und 
braucht von der CPU nicht für jedes Daten wort mit den Quell-, Halftone- und Zieldaten nach¬ 
geladen zu werden. 

Die erforderlichen Quell- und Zieldaten holt er sich als DMA-Baustein selbst aus dem RAM 
und legt sie nach Verarbeitung auch wieder dort ab. Außerdem verfügt er über ein eigenes 
schnelles Halftone-RAM. Zugriffe auf das RAM des ST muß der Blitter mit der CPU und der 
DMA-Einheit “absprechen”. 
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Bit-Block Verarbeitung 

Beim Bit-Block-Transfer werden Bitfeld-Daten aus einem Ursprungs-Speicherbereich mit 
den Daten eines Bitfelds im Ziel-Speicherbereich unter Verwendung eines Booleschen Opera¬ 
tors verknüpft. 

Die Verknüpfung wird dabei jeweils auf die zueinandergehörenden Bits des Quell- und Ziel¬ 
bitfelds angewendet. 

Folgende logische Verknüpfungsmöglichkeiten ergeben sich dabei: 


Verknüpfgs.-Nr. 

Ergebnis der Verknüpfung im Zielbitfeld 

0 

Zielbit = 0 

1 

Zielbit = Quellbit AND Zielbit 

2 

Zielbit = Quellbit AND NOT Zielbit 

3 

Zielbit = Quellbit 

4 

Zielbit - NOT Quellbit AND Zielbit 

5 

Zielbit = Zielbit 

6 

Zielbit = Quellbit XOR Zielbit 

7 

Zielbit = Quellbit OR Zielbit 

8 

Zielbit = NOT Quellbit AND NOT Zielbit 

9 

Zielbit = NOT Quellbit XOR Zielbit 

10 

Zielbit = NOT Zielbit 

11 

Zielbit = Quellbit OR NOT Zielbit 

12 

Zielbit = NOT Quellbit 

13 

Zielbit = NOT Quellbit OR Zielbit 

14 

Zielbit = NOT Quellbit OR NOT Zielbit 

15 

Zielbit = 1 


Bit-Block-Transfer mit dem Blitter 

Der ST-Blitter verfügt über eine Anzahl von Registern, die an den in der Abbildung 2.13 auf¬ 
geführten Adressen im Speicherraum des ST zu finden sind (sofern der Blitter eingebaut ist!). 

Blitter-Registerzugriffe müssen jedoch immer im Supervisor-Modus erfolgen, sonst “wirft” 
der ST Bomben! 

Zur Erläuterung des Ablaufes eines Bit-Block-Transfers mit dem Blitter soll das in Abbildung 
2.14 gezeigte Datenflußbild dienen. 
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$FF 8A00 
SFF 8A02 


Halftnne-ROH 


16 x 16 Bit 


ÄFF ÖA1E 

ÄFF 8A20 
ÄFF 8A22 
ÄFF 8A24 

ÄFF 8A28 
ÄFF 8A2A 
ÄFF 8A2C 

ÄFF 8A2E 
ÄFF 8A38 
ÄFF 8A32 

ÄFF 8A36 
ÄFF 8A38 
ÄFF 8A3A 
ÄFF 8A3B 
ÄFF 8A3C 


ÄFF 8A3D 



■Line NUMbfi-r- 

■SwjcJge- 

■HDQ 

■Busy 


Source X Increnent 
Source V Increwent 


JSource ftddress 


ENDMASK 1 
ENDMASK 2 
ENDMASK 3 

Destination X Increnent 
Destination V Increnen t 
I M I M I I lOT] 1 I I 1X1 Destination Address 

X Count 
V Count 


Abb. 2.13: Die Register des Blitter-Chips 



Abb. 2.14: Der Datenfluß beim Bit-Block-Transfer 
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Nun zur Arbeitsweise des Blitters. Betrachten wir zunächst eine einfache Blitter-Operation; 
Ein Bit-Block soll vollständig mit 0- oder 1 -Bits gefüllt werden. 

Zur Wahl der Verknüpfung muß das 

Operation-Register 


Adresse 

Zugriff 

Funktion 

Größe 

Label 

$FF 8A3B 

RAV 

Verknüpfungsart festlegen 

Byte 

OP 


im Blitter mit der entsprechenden Verknüpfungs-Nummer geladen werden (Beispiel: Füllen 
des Zielbitfeldes mit O-Bits=OP-Nr. 0, Füllen mit 1-Bits = OP-Nr. 15). Daten aus dem Quell¬ 
bitfeld und Halftone-RAM sind in diesem Fall nicht erforderlich (der Source-Buffer und das 
Halftone-RAM werden also nicht benötigt). Der für die Durchführung der logischen Verknüp- 
fung zuständige Funktionsblock (im Datenflußbild mit Log. OP bezeichnet) erzeugt die nöti¬ 
gen 0- bzw. 1-Bits für die Fülloperation. 

Bei jeder Blitter-Operation wird der Funktionsblock ENDMASK gebraucht. Hier muß näm¬ 
lich festgelegt werden, welche Bits im Zieldatenwort geändert werden müssen und welche 
nicht. Wenn alle Bits eines Wortes im Zielbitfeld mit 0- oder 1-Bits gefüllt werden, schreibt 
der Blitter einfach ein Datenwort nach dem anderen, ohne jemals Daten aus dem Zielbitfeld 
lesen zu müssen. Sind dagegen jedoch nicht alle Bits eines Wortes im Zielbitfeld zu ändern, 
so geben die ENDMASK-Register die Bitpositionen an, die im Zieldatenwort geändert wer¬ 
den müssen. 

ENDMASKl-Register 


Adresse 

Zugriff 

Funktion 

Größe 

Label 

SFF8A28 

RAV 

Zu ändernde Zielbits 

Word 

Endmaskl 



(Zeilenanfang) 




Dieses Register legt fest, welche Bits im ersten Datenwort einer Zeile des Zielbitfeldes geän¬ 
dert werden sollen. 

ENDMASK2-Register 


Adresse 

Zugriff 

Funktion 

Größe 

Label 

$FF 8A2A 

RAV 

Zu ändernde Zielbits 

Word 

Endmask2 
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Wird benutzt, wenn keines der anderen beiden ENDMASK-Register angewendet wird (das 
ist für alle Datenworte zwischen dem ersten und letzten Datenwort einer Zeile des Zielbitfeldes 
der Fall). 

ENDMASK3-Register 


Adresse 

Zugriff 

Funktion 

Größe 

Label 

$FF 8A2C 

RAV 

Zu ändernde Zielbits 

Word 

Endmask2 



(Zeilenende) 




Für das Schreiben des letzten Datenworts einer Zeile im Zielbitfeld wird dieses Register als 
Maske benutzt, um festzulegen, welche Bits geändert werden müssen. 

Folglich ist also immer dann ein READ-MODIFY-WRITE-Zyklus für das Zieldatenwort 
erforderlich, wenn in dem zugehörigen ENDMASK-Register nicht alle Bits gesetzt sind (zur 
Veranschaulichung dient die Abbildung 2.15). 


Date-nwort K 


Datenwort k+1 


Datenwort R+2 


ENPliftSKl- IT i i i i i ii i ii iBmmiBi =$0D0F irerd-mod ifv-write) 
EHDHflSK2= =SFFFF tWRITE onia» 

EHDMftSK3- isr»i«wiwi»i»i i i I I ITTI =SFF88 crehd-mooifv-writei 


Zeile N 
Zeile N+1 
Zeile N+S 



ein Aus¬ 
schnitt aus 
den Bild- 
schirnspei- 
cherbereich 
(HonochroH- 
betriebs- 
artJ 


Abb. 2.15: Eine einfache Aufgabe für den Blilter: das Füllen eines Zielbitfeldes mit 1-Bits 
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Ist eine Zeile des Zielbitfelds übrigens “schmaler” als ein Datenwort (z. B. nur 12 Bit breit), 
so wird nur das ENDMASKl-Register benutzt. 

Nachdem der Blitter ein Datenwort im Zielspeicherbereich bearbeitet hat, muß die nächste 
zu bearbeitende Adresse ermittelt werden. Dazu benötigt der Blitter die Angaben im 
Destination-X-Increment-, Destination-Y-Increment-, X-Count-, Y-Count- und Destination- 
Address-Register. 

Mit diesen Registern wird sozusagen der zu bearbeitende Bitblock von seinen Abmessungen 
her festgelegt. 

X-Count-Register 


Adresse 

Zugriff 

Funktion 

Größe 

Label 

$FF 8A36 

RAV 

Anzahl Words/Zeile im 
Zielbitfeld 

Word 

X_Count 


Hiermit wird festgelegt, wie viele Datenworte zu einer Zeile des Zielbitfeldes gehören (in dem 
Beispiel in der Abbildung 2.15 steht also hier ein Wert von 3). 

Der kleinste Wert ist 1 (mindestens ein Datenwort muß im Zielspeicherbereich schon zu 
bearbeiten sein, sonst brauchtman jakeine Transferoperation durchzuführen!), und der größte 
Wert ist 65536 (wird durch einen Wert von $0000 dargestellt). 

Der Blitter zählt jedesmal dann den Inhalt des Registers um 1 herunter, wenn er ein Daten wort 
geschrieben hat. Bei Erreichen von $0000 wird automatisch das X-Count-Register wieder auf 
den ursprünglich programmierten Wert gesetzt. (Ähnlichkeiten in der Arbeitsweise mit dem 
Timer-Data-Register des MFP sind zufällig und nicht beabsichtigt.) Beim Auslesen erhält man 
die Zahl der Datenworte, die in der augenblicklich in Bearbeitung befindlichen Zeile noch 
geschrieben werden müssen. 

Y-Count-Register 


Adresse 

Zugriff 

Funktion 

Größe 

Label 

$FF 8A38 

RAV 

Zeilenzahl im Zielbitfeld 

Word 

Y_Count 


Gibt an, aus wie vielen Zeilen das Zielbitfeld besteht. Wertebereich wie beim X-Count- 
Register (mindestens eine Zeile, maximal 65536 Zeilen sind möglich. Im Beispiel in Abbil¬ 
dung 2.15 also ein Wert von 21). 
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Nachdem eine komplette Zeile des Zielbitfeldes geschrieben ist, wird der Inhalt des Registers 
jeweils um 1 vermindert. Bei $0000 ist der Transfer dann beendet! Ein Lesezugriff liefert die 
Zahl der Zeilen, die noch geschrieben werden müssen. 

Destination-X-Increment-Register 


Adresse 

Zugriff 

Funktion 

Größe 

Label 

$FF 8A2E 

RAV 

Distanz zwischen zwei Words 
im Zielbitfeld 

Word 

| Dst_Xinc 


Wird als vorzeichenbehaftete Zahl interpretiert (höchstwertiges Bit wird für Vorzeichen 
benutzt). Das niedrigstwertige Bit wird nicht benutzt, weil der Blitter immer mit Wordzugriffen 
arbeitet. Und die sind nur auf gerade Adressen erlaubt. 

Anzugeben ist in diesem Register der Abstand in Bytes zwischen zwei Datenwörtem einer 
Zeile des Zielbitfeldes (Achtung bei Bitplanes! In Low-Resolution steht hier also 8 oder -8, 
bei Mid-Resolution dann 4 bzw. -4 und im Monochrom-Modus entspr. 2 oder -2). Ein negati¬ 
ver Wert weist darauf hin, daß die Zeile von rechts nach links bearbeitet wird. 

Nachdem der Blitter ein Zieldatenwort geschrieben hat, wird der Wert aus dem Destination- 
X-Increment-Register unter Berücksichtigung seines Vorzeichens zudemlnhaltimDestination- 
Address-Register addiert (jedoch nur, wenn das X-Count-Register einen Wert <>1 hat, also 
eine Zeile im Zielbitfeld aus mehr als einem Datenwort besteht). 

So kann der Blitter in einstellbaren Schrittweiten den Zielspeicherbereich bearbeiten und nicht 
nur unmittelbar nebeneinanderliegende Datenwörter ansprechen (wichtig bei Bit-Blockr 
Transfers auf den Bitplanes in der niedrigen und mittleren Bildschirmauflösung, bei denen ja 
die zu einem Plane gehörigen Datenwörter nicht unmittelbar nebeneinander, sondern vier 
bzw. acht Bytes auseinanderliegen!). 

Destination-Y-Increment-Register 


Adresse 

Zugriff 

Funktion 

Größe 

Label 

$FF 8A30 

RAV 

Distanz zwischen zwei Zeilen 
im Zielbitfeld 

Word 

Dst_Yinc 


Daten werden auch hier vorzeichenbehaftet betrachtet. Das Register enthält den Byte-Abstand 
von der letzten Zieladresse einer Zeile zur ersten Zieladresse in der nächsten Zeile des 
Zielbitfeldes. Dieser Wert wird nach dem Schreiben des letzten Datenworts einer Zeile 
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vorzeichenrichtig zum Inhalt des Destination-Address-Registers addiert. Somit zeigt das 
Destination-Address-Register dann wieder auf das nächste zu bearbeitende Zieldatenwort. 

Sollte das X-Count-Register von vornherein nur mit einem Wert von 1 geladen worden sein 
(weil eine Zeile im Zielbitfeld max. ein Datenwort breit ist), arbeitet der Blitter bei der Ermitt¬ 
lung der nächsten Zieldatenadresse ausschließlich mit dem Destination-Y-Increment-Regi- 
ster. Eine Zeile im Zielbitfeld besteht dann ja nur aus einem Daten wort, und nach Bearbeitung 
dieses einen Wortes ist schon die nächste Zeile an der Reihe. 

Destination-Adress-Register 


Adresse 

Zugriff 

Funktion 

Größe 

Label 

$FF 8A32 

R/W 

Zeiger auf (nächstes) 
Zieldatenwort 

Long 

Dst_Addr 


Zu Beginn eines Bit-Block-Transfers ist hier die Anfangsadresse des ersten Wortes des 
Zielbitfeldes einzutragen. Während des Transfers wird das Register ständig mit Hilfe der 
Werte im Destination-X-Increment- und Destination-Y-Increment-Register auf den aktuellen 
Stand gebracht. Man würde deshalb bei einem Lesezugriff während eines Transfers die 
Adresse des nächsten zu bearbeitenden Zieldatenwortes erhalten. 

Für etwas komplexere Operationen werden noch einige weitere Register gebraucht. Unter an¬ 
derem werden diese erforderlich, wenn z. B. ein Zielbitfeld mit Daten eines Musters AND- 
verknüpft werden soll. Als Ergebnis bleiben also im Zielbitfeld nur jene Bits gesetzt, die auch 
im Muster gesetzt sind, Hier kommt nun das Halftone-RAM (Größe: 16 Datenwörter) ins 
Spiel. 

Zunächst wird das Muster, mit dem das Zielbitfeld verknüpft werden soll, als 16x16 Bitfeld 
ins Halftone-RAM eingeschrieben. Dann wird das OP-Register mit dem Wert für die AND- 
Verknüpfung (OP-Nr.l) geladen. Anschließend muß dem Blitter noch mitgeteilt werden, daß 
die Verknüpfung von Daten im Zielbitfeld nur mit dem Muster aus dem Halftone-RAM durch¬ 
geführt werden soll. 

Das geschieht über das 

Halftone-Operation-Register 


Adresse 

Zugriff 

Funktion 

Größe 

Label 

$FF 8A3A 

R/W 

Halftone-Verknüpfungsvorschrift 

Byte 

HOP 
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Folgende Möglichkeiten sind einstellbar: 


HOP 

Verknüpfungsergebnis 

0 

Alle Bits = 1 

1 

Nur Halftone-Daten 

2 

Nur Source-Daten 

3 

Source AND Halftone 


Das HOP-Register muß bei obigem Beispiel also mit dem Wert von I geladen werden, weil 
ja nur die Musterdaten aus dem Halftone-RAM benötigt werden (Achtung beim Registerzugriff! 
Das HOP-Register ist nur 1 Byte breit.) 

Außerdem kommt jetzt noch ein weiterer Parameter ins Spiel: 

Line-Number-Register 


Adresse 

Zugriff 

Funktion 

Größe 

Label 

$FF 8A3C 

R/W 

Zeiger auf 

Halftone-Verknüpfungsword 

Byte 

Line_Num 


Bei einer Halftone-Operation gibt die Line Number an (gebildet aus den niedrigstwertigen vier 
Bits in diesem Register), welchesder 16 WörterimHalftone-RAMals Verknüpfungsdatenwort 
für die gerade zu bearbeitende Zeile benutzt wird. 

Abhängig vom Destination-Y-Increment-Register wird am Ende einer Zeile die Line Number 
um 1 erhöht (bei positivem Wert in Destination-Y-Increment-Register) oder um 1 erniedrigt 
(bei negativem Wert im Destination-Y -Increment-Register), um so das nächste Verknüpfungs¬ 
datenwort im Halftone-RAM zu adressieren. Die Line Number wird “rund” gezählt, d. h., bei 
einem Wert von 15 wird bei weiterer Erhöhung der Zähler wieder bei 0 beginnen. Bei einer 
weiteren Dekrementierung bei einem Zählerstand von 0 wird die Line Number entsprechend 
auf 15 springen. 

Die schon bekannten Register (Destination-Address-, Destination-X-Increment, Destination- 
Y-Increment-, X-Count- und Y-Count-Register) werden entsprechend mit Werten, die sich 
aus der Lage und den “Abmessungen” des zu füllenden Zielbitfeldes ergeben, geladen. 

Im Prinzip funktioniert die ganze Angelegenheit genauso, wenn man statt des Musters aus dem 
Halftone-RAM ein Quellbitfeld zur Verknüpfung mit dem Zielbitfeld heranzieht. Nur das 
HOP-Register muß dann anders gesetzt werden (HOP-Nr.2 oder HOP-Nr.3). 
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Der Quellbitblock hat dann die gleichen “Abmessungen” wie der Zielbitblock (X-Count und 
Y-Count gelten sowohl für den Source- als auch den Destination-Bit-Block!). Unterscheiden 
dürfen sich jedoch die Werte für X-Increment und Y-Increment, weshalb auch für den 
Quellbitblock eigene Register zur Aufnahme dieser beiden Werte vorgesehen sind. 


Source-X-Increment-Register 


Adresse 

Zugriff 

Funktion 

Größe 

Label 

$FF 8A20 

RAV 

Distanz zwischen zwei 

Words im Quellbitfeld 

Word 

Src_Xinc 


Hier wird der Abstand (in B y tes) zwischen zwei Datenwörtern in einer Zeile des Quellbitblocks 
eingetragen (unter Berücksichtigung des Vorzeichens!). Nachdem jeweils ein Source-Wort 
gelesen wurde, wird der Wert dieses Registers zum Inhalt des Source-Address-Registers vor¬ 
zeichenrichtig addiert (solange X-Count <>1 ist!), 

Source-Y-Increment-Register 


1 

Adresse 

Zugriff 

Funktion 

Größe 

Label 

$FF 8A22 

RAV 

Distanz zwischen zwei 

Zeilen im Quellbitfeld 

Word 

SrcJYinc 


Abstand in Bytes zwischen dem letzten Wort einer Zeile des Quellbitfeldes und dem ersten 
Wort der nächsten Zeile (mit Vorzeichen!). 

Wenn das letzte Wort einer Zeile des Quellbitblocks gelesen ist, wird der Wert im Source-Y- 
Increment-Register zum Inhalt des Source-Address-Registers vorzeichenrichtig addiert. Das 
Source-Address-Register zeigt danach wieder auf das nächste zu lesende Datenwort des 
Quellbitfeldes. 

Source-Adress-Register 


Adresse 

Zugriff 

Funktion 

Größe 

Label 

$FF 8A24 

RAV 

Zeiger auf (nächstes) 
Zieldatenwort 

Long 

Src_Addr 


Zu Beginn eines Bit-Block-Transfers wird hier die Anfangsadresse des ersten Wortes des 
Quellbitfeldes eingetragen. 
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Während des Transfers wird das Source-Adress-Register ständig mit Hilfe der Werte im 
Source-X-Increment- und Source-Y-Increment-Register auf den aktuellen Stand gebracht. 
Bei einem Lesezugriff während des Transfers steht hier die Adresse des nächsten zu lesenden 
Quelldatenwortes. Werden Quellbitfeld-Daten in die Verarbeitung einbezogen, kommt der im 
Datenflußbild mit Source-Buffer bezeichnete Funktionsblock ins Spiel. Bei einer Bit-Block- 
Operation mit Sourcedaten spielt sich im Blitter dann folgendes ab (Zum besseren Verständnis 
sollte man die Abbildung 2.14 betrachten): 

Die ersten beiden Sourceworte werden in den Source-Buffer eingelesen. Zur Verküpfung mit 
den Zielbits im Zieldatenwort muß eine Justierung (Bitverschiebung) der Sourcedaten im 
Source-Buffer erfolgen (das erste Bit des Quellbitfeldes soll ja mit dem ersten Bit des Zielbit¬ 
feldes verknüpft werden usw.). Den Grad der Justierung erfahrt der Blitter aus dem SKEW- 
Register (dazu später mehr). 

Ist das erste Quelldatenwort (nach entsprechender Justierung) mit dem ersten Zieldatenwort 
verknüpft, werden die 16 niederwertigen Bits im Source-Buffer in die 16 höherwertigen Bits 
des Source-Buffers übertragen. Das nächste zu lesende Sourcewort gelangt in die niederwer¬ 
tigsten 16 Bit des Registers. Es erfolgt wieder die Justierung im Source Buffer, dann die Ver¬ 
knüpfung mit dem Zieldatenwort usw. 

Nun folgen noch die Erläuterungen für die verbleibenden Flags und Register. Unter der 
Adresse $FF 8A3D findet man die folgenden Flags und Werte: 

SKEW (Label: “Skew”) In die vier niederwertigsten Bits an Adresse $FF 8A3D 

muß der sogenannte Source-Skew eingetragen werden. Darunter versteht 
man die Zahl der nötigen Rechtsverschiebungen, die mit den Source-Daten 
im Source Buffer (siehe Datenflußschema) durchgeführt werden müssen, 
bevor diese Daten mit den Halftone- und Destination-Daten verknüpft wer¬ 
den dürfen. Beispiel'. Dargestellt sind jeweils die ersten beiden Datenworte 
des Quell- und Zielbitfeldes. 

Datenwort 1 Datenwort 2 


—c 

10000000000000 





10000000 



> 

SKEW 

= 6 

<- 


000000000 


Quell¬ 

bitfeld 


000000000000000 - 


Ziel- 

bitfeld 
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Der Quellbitblock beginnt im Beispiel bei Bit 13 im Datenwort 1 des 
Quellbitfeldes, während der Zielbitblock erst bei Bit 7 im ersten Datenwort 
des Zielbitfeldes anfängt! Damit also jeweils die zusammengehörigen Bits 
(das erste Bit im Quellbitblock korrespondiert ja mit dem ersten Bit im Ziel¬ 
bitblock usw.) miteinander verknüpft werden können, müssen diese erst 
“übereinandergeschoben” werden. 

Um wie viele Bitpositionen die Daten “geschoben” werden müssen, ist im 
Skew-Wert anzugeben. 

FXSR (Force Extra Source Read) Ist das höchstwertige Bit im Blitter-Register an 

Adresse $FF 8A3D gesetzt, so wird zu Beginn einer jeden Zeile ein zusätzli¬ 
ches Datenwort eingelesen, um entsprechend “Luft” für Verschiebungen 
im Source-Buffer zu schaffen. 

NFSR (No Final Source Read) Wenn Bit 6 im Blitter-Register an Adresse $FF 

8 A3D gesetzt ist, wird das letzte Quell-Datenwort einer Zeile nicht gelesen. 
Bei einigen Kombinationen von ENDMASK-Inhalten und SKEW-Werten 
kann auf das Lesen des letzten Daten wortes einer Zeile des Quellbitfeldes 
verzichtet werden. 

Zu den FXSR- und NFSR-Bits hier noch einige Erläuterungen: 

Ein Block mit einer Breite von beispielsweise 20 Bits benötigt mindestens zwei Datenworte/ 
Zeile zu seiner Darstellung. Je nachdem, bei welchem Bit des ersten Datenwortes das Bitfeld 
beginnt, können für die Darstellung dieses 20 Bit breiten Bitfeldes aber auch drei Datenworte/ 
Zeile nötig sein! Es ist also vorstellbar, daß im Quellbitfeld für die 20 Bits schon zwei Daten¬ 
worte/Zeile ausreichend sind, während im Zielbitfeld drei Datenworte erforderlich sind. Der 
umgekehrte Fall ist natürlich genauso denkbar. 

Daraus folgtdieNotwendigkeit, evtl, eine unterschiedliche Zahl von Lese- und Schreibzugriffen 
in einer Zeile des Bit-Blocks durchführen zu müssen. Für diese Steuerung sind die beiden Bits 
FXSR und NFSR erforderlich. 

Die folgenden Beispiele zeigen, abhängig von der Lage der Quell- und Zielbitfelder 
zueinander, die jeweils nötige Einstellung der FXSR- und NFSR-Bits: (Die Bearbeitung soll 


von rechts nach links erfolgen!) 

S = Sourcebits D = Dcstin.-Bits FXSR NFSR 

-SSSSSSSSSSSS SSSSSSSS- 0 0 

-ddddddddd ddddddddddd- 





854 


ATARI Profibuch 


S = Sourcebits D = Destin.-Bits 


FXSR NFSR 


-ssssssssssss 

- DD 


ssssssss- 

DDDDDDDDDDDDDDDD DD' 


0 1 


- s SSSSSSSSSSSSSSSS SSS 

■DDDDDDDDD DDDDDDDDDDD- 


1 0 


-SSSSSSSSSSSS SSSSSSSS 

—DDDDDDDDDDDDDD DDDDDD- 


1 0 


An Adresse $FF 8A3C (Label: “Line_Num”, also dort, wo auch die Line Number zu finden 
ist) existieren noch die folgenden Steuerbits: 

SMUDGE Dieses Bit befindet sich an der gleichen Adresse wie die Line Number für 
das Halftone-RAM ($FF 8A3C). Ist es gesetzt, bestimmt nicht die Line 
Number, welches Datenwort aus dem Halftone-RAM bei einer Halftone- 
Operation zur Verknüpfung benutzt wird, sondern die nieder wertigsten vier 
Bits der verschobenen (ge”SKEW”ten) Sourcedaten im Source-Buffer, 
Das ergibt quasi zufällige Verknüpfungen mit den Daten im Halftone-RAM 
und kann für “Schmiereffekte” benutzt werden. 

HOG Hier wird die Betriebsart des Blitters eingestellt. Bei gelöschtem Bit teilen 

sich CPU und Blitter Zugriffe auf den Bus zu gleichen Teilen auf. Jeder darf 
für 64 Zyklen an den Bus, während der andere angehalten wird! 

- Ist das HOG-Bit gesetzt, wird die CPU so lange angehalten, bis der 
Bit-Block-Transfer beendet ist. Es darf aber durchaus die CPU mal 
den einen oder anderen Befehl ausführen, wenn der Blitter zwischen¬ 
durch mal den Bus freigibt! Mit gesetztem HOG-Bit kann der Bit- 
Block-Transfer bis zu doppelt so schnell abgewickelt werden, als 
wenn sich CPU und Blitter den Bus im Verhältnis 1:1 teilen müssen. 
In beiden Betriebsmodi nimmt der Blitter aber Rücksicht auf den 
DMA-Baustein. Dieser hat nämlich Vorrang! 

- ATARI betreibt den Blitter standardmäßig mit gelöschtem HOG-Bit 
(CPU und Blitter teilen sich Buszugriffe für jeweils 64 Buszyklen). 
Um jedoch nahezu die gleiche Verarbeitungsgeschwindigkeit wie 
bei gesetztem HOG-Bit zu erreichen (ca. 90% des HOG-Modus), 
macht die CPU während “ihrer” 64 Busszyklen nichts anderes, als 
den Blitter sofort wieder neu zu starten, so daß dieser unmittelbar 
(nach ca. sieben CPU-Buszyklen) die Buskontrolle zurückbekommt! 
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Progrannbeispiel: 


STBRT: 

lea Line-Hun,BÖ 

bset.b #H0GBIT,(B8) 

i Pointer auf HÜG-Register -> BB 
: HOG-Bit löschen (Kein HOG-Rodus!) 

RESTBRT : 

bset.b «BUSYBIT,(HB) 
nop 

bne.s RESTBRT 

■ 

■ 

j BUSY-Bit testen u. setzen (startet 
; den BLITTER sofort nieder neu!) 
j Der "nop"-Befehl wird noch ausgeführt, 
j bevor der Blitter neu startet! 


Abb. 2.16: Programmbeispiel 


BUSY Wenn alle anderen Register des Blitters gesetzt sind, wird durch Setzen des 

BUSY-Bits im Blitter der Transfer ausgelöst. Der auf das Setzen des BUSY- 
Bits folgende Befehl wird von der CPU in der Regel aber noch ausgeführt, 
bevor der Blitter das Regiment übernimmt! 

Die Interrupt-Leitung zum MFP, Port 13 (GPU done), ist direkt mit diesem 
Bit gekoppelt. Wenn der Blitter fertig ist, wird das BUSY-Bit zurückge¬ 
setzt, und die GPU-done-Leitung geht zurück auf Low. 


Wer’s gerne knifflig mag, 

kann den Blitter ja direkt programmieren. Die besprochenen Register und Steuerbits müssen 
jedoch alle vom Programmierer vor dem Bit-Block-Transfer selbst gesetzt werden! Die 
Beispiele für SKEW, NFSR,FXSRusw. waren janochrelativ anschaulich. Wer Lusthat,kann 
sich ja mal überlegen, was alles zu beachten ist, wenn sich zu übertragende Bitblöcke überlap¬ 
pen (und dabei gibt’s dann noch die Möglichkeiten, daß die Sourceadresse kleiner oder größer 
als die Zieladresse ist)! 

Aber ATARI hat den Bit-Block-Transfer in neueren TOS-Versionen “transparent” für den 
Programmierer ausgelegt. Das bedeutet nichts anderes, als daß die BitBlt-Funktion die mit der 
Line-AFunktion SA007 aufgerufen wird, sowohl durch den Blitter als auch in Softwareemulation 
durch die CPU (wie gehabt) ausgeführt werden kann. Wenn der Blitter eingebaut ist, bietet 
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einem das TOS in der Desktop-Menüleiste unter dem Eintrag “Extras” die Möglichkeit, diesen 
ein- und auszuschalten. Die gleiche Funktion ist mit dem XBIOS-Aufruf #64 (“Blitmode”) 
möglich. Sie kann auch benutzt werden, um abzufragen, ob der Blitter eingebaut ist. Näheres 
dazu in Teil I, Kapitel 1, in der “XBIOS-Referenz”. Zur hardwaremäßigen Einbindung des 
Blitters sei auf die Abbildung 2.17 verwiesen. 


Wie dort zu sehen, handelt es sich beim Blitter mit seinen 23 Adreß- und 16 Datenleitungen 
sowie dem kompletten Satz an Steuer- und Meldeanschlüssen um einen vollwertigen Mikro- 



Abb. 2.17: Die Einbindung des BUTTERs in die ST-Hardware 
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Prozessor, der sich in einem 68000er-System “zu Hause” fühlt. Als eigenständiges DMA- 
Device kann er deshalb in einem 68000er-System die Bussteuerung übernehmen. 

DieTaktversorgung erfolgt ebenfalls mit dem gleichen 8-MHz-Takt, wie ihn die CPU des ST 
erhält. 

Auf die einzelnen Steuer- und Meldeleitungen im einzelnen einzugehen,würde den Rahmen 
sprengen. Außerdem haben diese im Prinzip die gleiche Funktion wie bei einer 68000er-CPU 
(ein paar Informationen finden sich auch in Teil II, Kapitel I, im Abschnitt über den System¬ 
bus des MEGA ST). 

Die Anschlüsse BGI und BGO dienen der Verkettung des Blitters mit den anderen DMA- 
Einheiten des ST. Das Signa] BG (Bus Grant = Bus Freigabesignal) gelangt nämlich von der 
CPU an BGI (Bus Grant In) des Blitters und von dessen BGO-Anschluß (Bus Grant Out) wieder 
hinaus anBGIdes GLUE-Chips (der einen Großteil derDMA-Logikdes ST enthält). Ebenfalls 
wird das BGACK-Signal vom GLUE erstdurch BGKI - BGACKdes Blitters “gefädelt”, bevor 
es dann als BGACK-Signal an die CPU gelangt. Damit bekommt der Blitter immer als erster 
mit, wenn die DMA-Einheit des ST den Bus beansprucht. 
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Kapitel 3: Der Soundgenerator 


Die ST-Computer können nicht nur per MIDI-Schnittstelle aktiv ins Musikgeschehen eingrci- 
fen, sondern sind auch in der Lage, eigene Laute von sich zu geben. So wird z. B. der Keyclick, 
die akustische Untermalung der Tastaturbedienung, von dem eingebauten Soundchip erzeugt. 

Die Konstrukteure von Atari haben hierbei auf einen Standard-Chip zurückgegriffen, der zwar 
nicht durch überragende Soundeigenschaften hervortritt, aber wohl ein recht gutes Kosten-/ 
Leistungsverhältnis aufweist. Zum Einsatz kommt ein Chip des Typs “YM 2149” von Yamaha 
oder der Typ “ AY-3-8910” von General Instruments. Beide sind untereinander voll hard- und 
softwarekompatibel. 

Die Tonerzeugung liegt voll unter Programmkontrolle, alle wesentlichen Parameter sind 
durch Software einstellbar. Der PSG (Programmable-Sound-Generator) wird mit einem aus 
dem Systemtakt gewonnenen 2 MHz Arbeitstakt versorgt. Daraus können mit Hilfe von drei 
programmierbaren Teilerstufen Ausgangsfrequenzen von 30 Hz bis 125 KHz erzeugt werden. 
Die Ausgangssignale haben Rechteckform. 


Rauschen erwünscht 

Ferner integriert in den PSG-Chip ist ein Rauschgenerator, dessen Ausgangssignal beliebig 
über eine Mixstufe mit den Ausgangssignalen der drei Tongeneratoren kombiniert werden 
kann. Das Rauschsignal ist ein Rechtecksignal, dessen Pulsbreite durch Pseudo-Zufallswerte 
bestimmt wird. 

Die CPU wird bei der Tonerzeugung nur wenig benötigt, da der PSG ein gewisses Maß an 
Eigenintelligenz besitzt. Sind die für einen bestimmten Sound nötigen Parameter in den Regi¬ 
stern des PSG eingestellt, so liegt die eigentliche ‘ ‘Arbeit” der Tonerzeugung beim Soundchip. 
Die CPU muß nur aktiv werden, wenn der Sound verändert werden soll. 


Lautstärke unter Programmkontrolle 

Zur Beeinflussung der Lautstärke der erzeugten Töne steht für jeden der drei Soundkanäle ein 
elektronischer Lautstarke-Steller zurVerfügung. Es besteht die Möglichkeit, die Ausgangsam¬ 
plitude (Lautstärke) in 16 Stufen einzustellen. Diese Abstufung verläuft nicht linear, sondern 
logarithmisch und ist damit dem Hörempfinden des menschlichen Ohres besser angepaßt. 
Weiterhin bietet der PSG die Möglichkeit, bestimmte Lautstärkeverläufe eines Tones abzuru- 
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fen und damit den Amplitudenverlauf des Ausgangssignals zu steuern. Acht solcher Hüllkurven 
(Envelopes) sind bereits vorprogrammiert und können abgerufen werden. 
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Ahb. 3.2 : Die Hüllkurve um ein Rechtecksignal 


Nicht nur Töne werden erzeugt 

Zusätzlich zu seinen Tongeneratoren besitzt der PSG-Chip noch zwei I/O-Ports, die zur 
Bedienung der parallelen Schnittstelle, der seriellen Schnittstelle und für die Erzeugung eini¬ 
ger Steuersignale für die Floppy-Disk-Steuerung benutzt werden. 

Zur gesamten Steuerung aller Funktionen des PSG besitzt dieser 16 Register mit jeweils 8 Bit 
Breite (also Bytezugriffe erforderlich!). 

Diese 16 Register sind jedoch nicht direkt zugänglich, sprich an 16 verschiedenen Adressen 
im I/O-Speicherraum des ST zu finden, sondern werden folgendermaßen angesprochen: 

In die Speicherstelle $FF 8800 (Label: “giselect”) wird die Nummer des Registers einge¬ 
schrieben, das angesprochen werden soll (Registemummer 0..15). 

- Soll der Inhalt des so ausgewählten Registers verändert werden, so muß dessen neuer 
Inhalt an Speicherstelle $FF 8802 (Label: “giwrite”) geschrieben werden. 

— Den Inhalt eines selektierten Registers kann man an Adresse $FF 8800 (Label: “giread”) 
auslesen. 
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Diese Art von Zugriff mag umständlich erscheinen, ist jedoch auf die Hardwaregegebenheiten 
des PSG-Chips zurückzuführen (Gemultiplexter Adreß- und Datenbus)! Ein Vorteil dieser 
Zugriffsart liegt darin, daß alle PSG-Register für eine Zugriffsart (Schreiben oder Lesen) auf 
der gleichen Speicherstelle zu finden sind. So entfallen Adreßberechnungen für Zugriffe auf 
verschiedene Register, Es wird so lange auf das gleiche PSG-Register zugegriffen, bis ein 
anderes ausgewählt wild. 
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Abb. 3.3: Die Register des Soundchips 


Nun zur Bedeutung der einzelnen Register, wie in Abbildung 3.3 dargestellt: 

R0..R5 Jeder der drei Tongeneratoren besitzt zur Frequenzeinstellung zwei 8-Bit- 

Register. Die oberen vier Bits des höherwertigen Registers werden jedoch 
nicht benutzt, so daß sich insgesamt ein 4 + 8 = 12 Bit-Wert für die Tonfre¬ 
quenzsteuerung ergibt. Die Tonerzeugung geschieht dabei nach folgendem 
Prinzip: 






















































Der Soundgenerator 


863 


Der Arbeitstakt des PSG (2 MHz) wird zunächst durch 16 geteilt. Daraus 
ergibt sich als Eingangsfrequenz für die drei Tonerzeugungsstufen eine 
Frequenzvon 125 kHz. Dieser Takt gelangtin jeder derTonerzeugungsstufen 
auf eine Teilerstufe, deren Teilerfaktor durch den 12-Bit-Wert im zugehö¬ 
rigen “Tongenerator-Control-Register” bestimmt wird. Ist also z. B. im 
“Periodendauer-Generator-C-Register” der Wert wie folgt 



Bi-t 

7 6 

5 

4 

3 

2 

1 

0 

R4 

Periodendauer 

DD 

1 

0 

mm 

0 

0 


R5 

Generator C 



Ol 

e 

0 

KB 

Gu 


eingetragen (entspricht einem Wert von $03E8 heju (= 1000 dcz )), so ergibt 
sich daraus eine Ausgangsfirequenz für den Tongenerator C von: 

125 kHz / 1000 = 0.125 kHz = 125 Hz 

Je kleiner also der Wert im Tongenerator-Control-Register ist, desto heller 
klingt der erzeugte Ton. 

R6 Die für den Rauschgenerator maximal zur Verfügung stehende Frequenz ist 

ebenfalls 125 kHz. Diese Arbeitsfrequenz gelangt, analog zu der Ton¬ 
generator-Steuerung, auf eine mit dem “Tonhöhe-Rauschen-Register” zu 
programmierende Teilerstufe. Die daraus gewonnene Frequenz dient dem 
eigentlichen Rauschgenerator als Eingangsfrequenz. Auch hierbei gilt: Je 
kleiner der Wert im Register 6 (Tonhöhe Rauschen), desto heller klingt das 
Rauschen. 

Bild 7 Durch entsprechendes Setzen bzw. Löschen einzelner Bits in diesem 

Register 7 wird für jeden der drei möglichen Soundkanäle eingestellt, ob ein 
“reiner” Ton erzeugt wird oder ob dieser mit Rauschen vom Rauschgenerator 
unterlegt wird. 

Die Steuerung erfolgt Low-aktiv, d. h., bei gelöschtem Bit ist die entspre¬ 
chende Funktion angewählt. Ist beispielsweise nur Bit 1 Low, dann wird nur 
das Signal des Tongenerators B weiter verwendet. Wird jetzt noch zusätz¬ 
lich Bit 4 Low, so wird das Signal des Tongenerators B mit dem Signal des 
Rauschgenerators zusammengemischt. Außerdem wird durch Register 7 
(Bit 6. .7) festgelegt, ob die I/O-Ports des PSG als Eingänge oder Ausgänge 
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arbeiten. Es ist jedoch nicht möglich, für jeden Anschluß der PSG-Ports 
separat (also bitweise) die Datenrichtung festzulegen! 

R8..R10 Die Register R8.. R10 steuern die “Lautstärkesteller” des PSG. Dabei sind 

die Bits “L0..L3” die sogenannten “Level-Control-Bits” und bestimmen 
den Ausgangspegel der drei Soundkanäle. 

Die Ausgangsamplitude läßt sich mit diesen vier Bits in 16 Stufen einstel¬ 
len. Ist das “M-Bit” gesetzt, wird der Verlauf der Ausgangsamplitude des 
entsprechenden Kanals nicht durch die Level-Control-Bits, sondern durch 
den Hüllkurvengenerator gesteuert. 

R11/R12 Der aus den 2 x 8 = 16 Bit der Register 11 und 12 des PSG gebildete Wert 

beeinflußt die Periodendauer der Hüllkurve. Die Form der Hüllkurve wird 
mit Register 13 ausgewählt. 

Als Eingangsfrequenz steht hierbei die durch 256 geteilte Taktfrequenz des 
PSG (2 MHz/256 = 7,8125 kHz) zur Verfügung. Diese wird entsprechend 
dem 16Bit-Wert in Register 11 und 12 weiter heruntergeteilt. Es lassen sich 
so Periodendauem von 128 uSek. (Reg. 11 + 12 = $0000) bis ca. acht Sek. 
(Reg. 11 + 12 = $FFFF) einstellen. 

R13 Mit den vier niederwertigen Bits des Registers 13 wird die Hüllkurvenform 

eingestellt, die durch den Hüllkurvengenerator erzeugt wird. Da nur ein 
Envelope-Generator vorhanden ist, gilt der Verlauf der Hüllkurve für alle 
Soundkanäle, für die das M-Bit im Amplitudenregister gesetzt ist. Es läßt 
sich also leider nicht für jeden Soundkanal eine eigene Hüllkurve einstel¬ 
len! Die oberen vier Bits des Registers haben keine Funktion. 

R14/R15 Über Register 14 und 15 wird der Datentransport mit den beiden I/O-Ports 

des PSG abgewickelt. Port A ist beim ST als Ausgang geschaltet und kon¬ 
trolliert einige Floppy-Disk-Steuerleitungen sowie Steuerleitungen der 
seriellen und parallelen Schnittstelle (siehe Abbildung 3.1). 

Port B bedient die Datenleitungen der parallelen Schnittstelle. 

Wie schon der Schaltungsauszug (Abbildung 3.1) zeigt, sind die drei Tonausgänge des PSG 

direkt miteinander verbunden. 

Das Summensignal der drei Soundkanäle gelangt über einen Impedanzwandler an Pin 1 der 

Monitorbuchse und kann dort abgenommen werden. 



Der Soundgenerator 



Periodendauer 
der Hüllkurve 


Abb. 3.4: Die Bedeutung der Steuerbits im Hüllkurvenform-Register (Reg. 13) 
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Es besteht die Möglichkeit, ein externes T onsignal über Pin 5 der Monitorbuchse einzuspeisen. 
Dieses Signal wird dann zu den vom PSG erzeugten Signalen hinzugemischt. Eine weitere 
Beeinflussung des externen zugeführten Signals ist nicht möglich. 

Von Port A des PSG sind die Ausgänge IOA6 und IOA7 im ST nicht weiter benutzt und stehen 
dem Endbenutzer für eigene Anwendungen zur Verfügung (viele Erweiterungen wie z. B. 16 
MHz-Beschleunigerkarten benutzen diese freien Ports). Die Ausgänge können eine Standard- 
TTL-Last treiben. 

- IOA6 ist auf Pin 3 der Monitorbuchse geführt und kann dort abgegriffen werden. 
IOA7 ist nur im ST am PSG direkt abzugreifen und nicht nach außen geführt. 


Betriebssystemunterstützter Sound 

Der PSG ist von den Systemprogrammierem bei der Programmierung des Betriebssystem 
berücksichtigt worden. Für das Löschen bzw. Setzen einzelner Bits in I/O-Port A des PSG sind 
die XBIOS-Funktionen #29 und #30 (“Offgibit” und “Ongibit”) vorgesehen. Mit der XBIOS- 
Funktion #28 (“Giaccess”) kann auf jedes Register des PSG zugegriffen werden. 

Außerdem ist ein Pseudo-Sound-Prozessor mit eigenem Pseudo-Befehlssatz per XBIOS- 
Aufruf (siehe XBIOS-Funktion #32, “Dosound”) aufrufbar. Dieser Aufruf erlaubt das relativ 
einfache Programmieren von Soundeffekten, welche quasi neben einem anderen Programm 
ablaufen können (im Timer C-Interrupt). Durch die Verwendung des Port A des PSG für die 
Floppy-Disk-Steuerung ist das unmittelbare Ansprechen derFloppy-Steuerleitungen des PSG 
aus z. B.. BASIC heraus, durch PEEK- und POKE-Befehle etwas schwierig. 

Während des VBlank-Interrupts, also alle 20 mSek. bei Farbbetriebsart bzw. alle 14 mSek. 
in Monochrombetriebsart, werden nämlich vom Betriebssystem die angeschlossenen Disk¬ 
laufwerke abgefragt, um festzustellen, ob der Motor noch läuft. Wenn dieser nicht mehr läuft, 
wird das entsprechende Laufwerk deselektiert. Um jedoch festzustellen, ob der Motor noch 
läuft, muß das entsprechende Disklaufwerk jeweils selektiert werden. Das erfolgt über den 
PSG, Port A, Leitung 1 oder 2. 

Es ist also bei PEEK und POKE aus BASIC heraus ziemlich wahrscheinlich, daß zwischen 
einer vom Anwender erfolgten Registerauswahl im PSG und dem Beschreiben oder Lesen des 
selektierten Registers der VBlank-Interrupt des Betriebssystems dazwischenrutscht. 

Diese Routine selektiert aber immer das Port A-Register, um dort mit den Drive-Select-Lei- 
tungen “herumzuspielen”. Leider ist diese Routine des Betriebssystems nicht so program- 
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miert, daß sie den Zustand des PSG nach Laufwerksselektion wieder so herstellt, wie er vor 
Laufwerksauswahl vorgefunden wurde! 

Deshalb ist es empfehlenswert, bei Registerzugriffen auf den PSG-Chip aus Hochsprachen 
wie z. B.. BASIC heraus die Betriebssystemroutinen zu verwenden. 

Hier als Beispiel ein kleines OMIKRON.BASIC-Programm zum Auslesen der Register des 
ST-Soundchips unter Benutzung der XBIOS-Funktion #28, “Giaccess”: 


100 1 Progrann zun Auslesen der 16 Register des ST-Soundchips 
110 ' durch Benutzung der XBIOS-Funktion "Giaccess" (XBIflS «28) 
120 1 
130 CLS 
140 PRINT 

150 PRINT TAB (10);" Registerinhalte des PSß-Chips" 

160 PRINT TAB (10)■»================================='' 

170 PRINT 

180 PRINT 11 PSG-Register | 7 I 6 I 5 I 4 I 3 I 2 I 1 I 0 I" 

190 PRINT " -—+—+—+-—+—+—+" 

200 FOR Register*^ TO 15 
210 USING "tttttt" 

220 PRINT " Register "{Register*!;" I "J 

230 Print-Bits(RegisterX) 

240 HEXT Register*! 

250 END 
260 1 

270 1 Registerinhalt in Tabellenfarn ausgeben 
280 1 

290 DEF PRDC Print_Bits(Register*!) 

300 XBIOS (Wert*!;28,0,Register*!) 

310 USING "#0 | tt | tt | tt | tt | tt | tt | tt I" 

320 PRINT RIGHTS( STR$( UAL( BIHS(MertK))),31) 

330 RETURN 


Abb. 3.5: Auslesen der PSG-Registerinhalte 








Kapitel 4: Der Multifunktionsbaustein 
MFP 68901 


Der MFP (Multi Function Peripheral - Peripherie-Baustein mit Mehrfach-Funktion) ist ein 
“Familienmitglied” der MC 68000-Serie und arbeitet deshalb sehr eng mit der 68000er CPU 
zusammen. Im ATARI ST übernimmt der MFP eine Reihe von Aufgaben. 


USART 

Der USART (Universal Synchronous/Asynchronous Receiver/Transm itter = Universeller 
Synchron-/Asynchron Empfänger/Sender) bedient die serielle Schnittstelle des ST. Näheres 
über diese Funktionseinheit des MFP ist bei der Beschreibung der seriellen Schnittstelle des 
ST zu finden. 


8-Bit-Parallelport 

Der MFP besitzt 8 I/O-Anschlüsse (den General Purpose Input/Output Interrupt Port=GPIP). 
Jeder Anschluß kann für sich als Ein- bzw. Ausgang geschaltet werden. Beim ST sind jedoch 
alle acht Anschlüsse als Eingänge programmiert und auch belegt. Außerdem kann jeder als 
Eingang geschaltete Anschluß des MFP auch als Interrupt-Eingang benutzt werden. Durch 
entsprechende Programmierung kann eingestellt werden, ob ein Interrupt bei steigender oder 
fallender Eingangs-Signalflanke ausgelöst werden soll. 

Der Parallelport wird mit drei Registern zu je 8 Bit Breite gesteuert (siehe auch Übersichtsbild 
des MFP-GPIP, Abbildung 4.1). Diese Register haben folgende Funktionen: 


Adresse Zugriff Funktion des Registers Label 

$FF FA01 R GPIP-Data-Register (GPIP) “GPIP” 

Das Auslesen dieses Register liefert die log. Pegel der entspre¬ 
chenden Eingangsanschlüsse. 

Bit 0 stellt den Pegel auf der BUSY-Leitung der parallelen 
Schnittstelle des ST dar. Bei nicht angeschlossenem Drucker ist 
dieses Bit gesetzt (Anschluß liegt über Pull-Up-Widerstand an 
+5V). 
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Adresse Zugriff Funktion des Registers Label 


SFFFA01 R GPIP-Data-Register (GPIP) “GPIP” 

Die Bits 1,2 und6(- Inputs II, 12 und 16) werden im ST für das 
Handshaking mit der seriellen Schnittstelle benutzt. 

Der Eingang 13 wird nur in STs mit Blitter benutzt. Er ist für das 
“GPU-Done”-Signal vom Blitter-Chip vorgesehen, der hiermit 
einem Low meldet, wenn eine BitBlt-Operation abgeschlossen 
wurde. 

Mit Bit 4 melden die beiden ACIAs (Asynchronous-Communi- 
cation-Interface-Adapter) unter anderem den Zeichenempfang 
von der Tastatur oder der MIDI-Schnittstelle. Tritt ein Interrupt 
von den ACIAs auf, wird die Leitung 14 auf Low gezogen. 

Welcher ACIA mit seiner ERQ-Leitung “geläutet” hat, wird vom 
Betriebssystem durch Abfrage der beiden ACIA-Statusregister 
ermittelt. 

Port 15 ist wichtig für die Überwachung des Floppy-Disk- 
Controllers. Durch Abfrage des Bit 5 wird getestet, ob der Flop- 
py-ControIler einen Befehl beendet hat. 

Außerdem melden hierüber evtl, am ACSI-Bus angeschlossene 
TARGETs den Abschluß eines Datenaustauschs über diesen 
schnellen DMA-Bus. 

Ein Low an diesem Eingang signalisiert also einen Interrupt 
durch den FDC oder den ACSI-Bus. 

Eingang 17 “lauscht” an der Monochrom-Detect-Leitung der 
Monitor-Buchse. Ist der Monochrom-Monitor angeschlossen, 
liegt Eingang 17 auf Low-Potential. 

Wird z. B. im Monochrom-Betrieb der Stecker des Monitors 
abgezogen und ein Farbmonitor angeschlossen, so wird dies vom 
Betriebssystem im Vertikal-Blank-Interrupt festgestellt und die 
neue Betriebsart eingestellt (über eine Neuinitialisierung des 
Systems). 
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Abb. 4.1: Der General-Puipose-IlO-Port (GP1P) des MFP (MC68901) im ATARI ST 
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Adresse Zugriff Funktion des Registers Label 


SFFFA03 RAV Active-Edge-Register (AER) “AER” 

Hiermit läßt sich einstellen, wann durch einen der acht Eingänge 
ein Interrupt ausgelöst wird. Bit 0 ist hierbei dem Anschluß 10 
zugeordnet, Bit 1 dem Anschluß II usw. Bei gelöschtem Bit 
erfolgt ein Interrupt bei einem High -> Low-Übergang, bei ge¬ 
setztem Bit wird bei Low-> High-Übergang unterbrochen. 

Die zugehörigen Interrupts werden mit den Namen der Ports 
bezeichnet. Interrupt II wird also durch Port II ausgelöst, In¬ 
terrupt 12 durch Port 12 usw. Zu der Interruptbehandlung des 
MFP jedoch später mehr. 

$FF FA05 RAV Data-Direction-Register (DDR) “DDR” 

Im DDR wird festgelegt, welche der acht I/O-Anschlüsse als 
Eingang und welche als Ausgang arbeiten. Im Gegensatz zum 
Soundchip (PSG) kann hier für jeden einzelnen Portanschluß die 
Datenrichtung festgelegt werden. 

Ein gesetztes Bit bedeutet hierbei, daß der zugehörige Port¬ 
anschluß als Ausgang arbeitet. Bei einem gelöschten Bit ist also 
der entsprechende Port als Eingang programmiert. 

Beim ST sind alle Ports als Eingang geschaltet. Alle Bits sind 
also gelöscht. 


Timer 

Der MFP besitzt vier Timer (Zeitgeber) zu je acht Bit. Gesteuert werden die Timer von einem 
eigenen Oszillator. Man hat die Möglichkeit, einen Quarz zwischen die Anschlüsse XTALO 
und XTAL1 zu “setzen” oder über XTALO einen Takt mit TTL-Pegel einzuspeisen. 

Die Timer können damit völlig unabhängig von dem am CLK-Eingang des MFP anliegenden 
Takt oder sonstigen im System verwendeten Takten arbeiten. (Der CLK-Takt dient lediglich 
der Steuerung des internen Timing im MFP und muß nicht unbedingt der Systemtakt sein oder 
zu diesem in Phase liegen). Der Ausgang des Timer-Takt-Oszillators speist alle vier Vorteiler 
der Timer des MFP mit einer Frequenz von 2,4576 MHz. 
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Abb. 4.2: Die Timer des MFP (MC68901) im ATARI ST 


Für jeden der vier Timer ist ein eigener Interruptkanal vorgesehen. Damit kann z.B. nach einer 
mit dem Timer voreingestellten Zeitdauer (= Zahl von Taktzyklen) ein Interrupt ausgelöst 
werden. 

Die Timer des MFP können in verschiedenen Betriebsarten arbeiten. Die Funktionsweisen 
werden nun kurz vorgestellt. 
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Reaktion mit Verzögerung - Der Delay Mode 

Alle vier Timer können als Verzögerungs-Timer arbeiten. In diesem Delay Mode wechseln 
die Timer-Ausgänge ihren log. Zustand, wenn eine bestimmte, programmierbare Zahl von 
Taktzyklen nach Starten des Timers abgelaufen ist. Außerdem wird dann ein Interrupt für die¬ 
sen Timer ausgelöst (sofern dieser aktiviert ist). Im Delay Mode arbeiten die Timer nach fol¬ 
gendem Prinzip: 

- Der MFP-Timer-Oszillator liefert den 2,4576 MHz-Arbeitstakt an die programmierbaren 
Vorteiler. Die auf die Vorteilerstufen folgenden Abwärtszähler erhalten immer dann 
einen Impuls von der Vorteilerstufe, wenn diese die eingestellte Anzahl von Taktzyklen 
“gesehen” hat. Bei einem Vorteilerverhältnis von 1:10 gelangt also nach je zehn Takt- 
zyklen ein Ausgangsimpuls zum Abwärtszähler. 

- Jeder Impuls vom Vorteiler erniedrigt den Zählerstand im Abwärtszähler um 1. Hat der 
Abwärtszähler einen Zählerstand von 1 erreicht, wird durch den nächsten Impuls vom 
Vorteiler der log. Zustand des Timer-Ausgangs geändert. Gleichzeitig wird der Abwärts¬ 
zähler wieder auf einen Anfangszählerstand gesetzt (dieser Anfangs wert wird im Timer- 
Data-Register eingestellt) und ein Interrupt für den entsprechenden Timer ausgelöst 
(sofem dieser zugelassen ist). 

Dazu ein Beispiel: 

Wenn der Vorteiler mit einem Teilerfaktor von 1/64 eingestellt wird, erhält der Abwärtszähler 
alle 64 Taktzyklen einen Impuls. Bei einer Taktfrequenz von 2,4576 MHz geschieht das somit 
alle 64/2 457 600 = 26,0417 pSek. 

Ist der Abwärtszähler über das Timer-Data-Register mit einem Wert von 64 geladen worden, 
so wechseltderTimerausgang seinen Zustand nach 64 Impulsen vom Vorteiler (= 64 x 26,0417 
pSek. = 1,6667 mSek.), und der Abwärtszähler wird wieder mit dem Wert aus dem Timer- 
Data-Register (im Beispiel = 64) nachgeladen. Nach weiteren 64 Impulsen vom Vorteiler (also 
nach 1,6667 mSek.) wechselt der Timerausgang wieder auf den Anfangszustand zurück, so 
daß eine volle Periode am Timerausgang 2x1,6667 mSek. = 3,333 mSek. dauert. Die erzeugte 
Ausgangsfrequenz beträgt dann 1 / 3,333 mSek. = 300 Hz. 


Grenzwerte im Timer-Data-Register 

Gibt man dem Timer-Data-Register einen Anfangszählerstand von 1, so wechselt der Timer¬ 
ausgang mit jedem Impuls vom Vorteiler seinen Zustand. Wird der Anfangszählerstand dage¬ 
gen auf 0 eingestellt, so sind 256 Impulse vom Vorteiler erforderlich, bevor sich am Timeraus¬ 
gang etwas “bewegt”. 
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Mit den Kombinationsmöglichkeiten, die der Vorteiler und der Abwärtszähler des MFP im 
Delay Mode bieten, sind beim ST so Verzögerungszeiten von 1,6276 uSek. bis 20,8333 mSek. 
zu realisieren. Durch die “krumme” Quarzfrequenz lassen sich insbesondere die gebräuchlich¬ 
sten Taktffequenzen für die serielle Datenübertragung einstellen! 


Am Puls des Geschehens - Die Pulsbreitenmessung 

Während der Delay Mode mit allen vier Timern möglich ist, können die Timer A und B noch 
ein wenig mehr. Wie aus dem Übersichtsbild ersichtlich ist (Abbildung 4.2), besitzen diese 
beiden Timer zusätzlich noch je einen externen Eingang TAI (Timer-A-Input) bzw. TBI (Ti- 
mer-B-Input). Mit Hilfe dieses Eingangs läßt sich die Zeitdauer eines Ereignisses feststellen. 

Für die Dauer des Ereignisses muß ein entsprechender “Ein”-Pegel an dem TAI- oder TBI- 
Anschluß anliegen. Beim ST ist jedoch lediglich der Timer-A-Eingang (TAI) ohne weiteres 
von außen zugänglich. Er ist, wie aus Abbildung 4.2 ersichtlich, mit dem BUS Y-Anschluß (Pin 
11) der parallelen Schnittstelle verbunden. 

Der Timer verhält sich in der Betriebsart “Pulsbreitenmessung” ähnlich wie im Delay Mode 
(derprogrammierbare Vorteiler liefert auch hier Impulse an den nachfolgenden Abwärtszähler). 
Während Ein-Pegel anliegt, zählt der Abwährtszähler im Timer A (bzw. B) wie im Delay 
Mode im Takt der vom Vorteiler eingehenden Impulse herunter. Geht der TAI-Anschluß 
(bzw. TBI) auf Aus-Pegel, wird der Zählvorgang gestoppt. 

Da man den Startwert des Abwärtszählers ja über das Timer-Data-Register zu Beginn der Puls¬ 
breitenmessung eingestellt hat, kann man nun über die Zahl der Impulse, die der Zähler bis 
zum Stoppen heruntergezählt hat, die Zeit ermitteln, für die Anschluß TAI (bzw. TBI) auf Ein- 
Pegel lag. 


Was ist für den Timer denn nun Ein-Pegel? 

Was am Timer-Eingang TAI (bzw. TBI) als Ein-Pegel gelten soll, wird durch Bit 4 (für Timer 
A) bzw. Bit 3 (für Timer B) im Aktive-Edge-Register (Label “AER” an Adresse $FF FA03) 
des MFP eingestellt. Ist das entsprechende Bit gesetzt, so wertet der Timer-Eingang ein High- 
Sigml als Ein-Pegel, und dementsprechend wird bei gelöschtem Bit ein Low-Signal als Ein- 
Pegel angesehen. 

Mit den Bits des AER wird ja sonst festgelegt, mit welcher Signalflanke an den als Eingängen 
geschalteten I/O-Ports (10...17) des MFP ein Interrupt ausgelöst werden soll (siehe Beschrei¬ 
bung des 8-Bit-Parallelports, Active-Edge-Register). 
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Die zugehörigen Portanschlüsse 13 und 14 können in der Betriebsart Pulsbreitenmessung der 
Timer A und B als I/O-Ports weiterverwendet werden. Interrupts lassen sich darüber nicht 
mehr auslösen! Die Interruptkanäle 14 und 13 reagieren jetzt nur auf die Signalflanken am 
Timer-Eingang TAI bzw. TBI! Ein Interrupt wird jetzt ausgelöst, wenn ein Flankenwechsel 
an dem entsprechenden Timer-Eingang von Ein- auf Aus-Pegel stattfindet. Hierzu ein Bei¬ 
spiel: 


Timer A sei auf Betriebsart “Pulsbreitenmessung” programmiert. 

- Der Vorteiler A ist auf 1/10 eigestellt. 

Timer-A-Data-Register und somit der Abwärtszähler des Timers A seien mit einem 
Startwert von 200 geladen. 

- Bit 4 im Active-Edge-Register sei gelöscht (TAI erkennt also Ein-Pegel bei Low). 

- Timer A wird gestartet durch Low an TAI (BUS Y-Anschluß der parallelen Schnittstelle). 

- Stop für Timer A bei High an TAI und Auslösung eines I4-Interrupts (wenn dieser zuge¬ 
lassen ist). 

- Der Inhalt des Timers A wird aus dem Timer-A-Data-Register ausgelesen und lautet bei¬ 
spielsweise auf 100 (Stopwert). 



Abb. 43: Die Pulsbreitenmessung mit Timer A 
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Die Zeitdauer, für die TAI (der BUSY-Anschluß) auf Low war, beträgt also: 

(Startwert - Stopwert) (200 - 100) 

-- - = 407 uSek. 

Vorteiler x Taktfreq. 0,1 x 2,4576 MHz 

Man kann aber nun nicht nur Ereignisdauern erfassen, die im Wertebereich des 8-Bit- 
Abwärtszählers liegen. Sollte nämlich während der Pulsbreitenmessung der Abwärtszähler 
“durch” 1 zählen, so wird, genau wie im Delay-Modus, der Timerausgang TAO (oder TBO) 
seinen Ausgangspegel ändern, der Abwärtszähler mit dem Wert aus dem Timer-Data-Register 
neu geladen und ein Timer-Interrupt auf dem entsprechenden Interruptkanal ausgelöst (sofern 
dieser aktiviert ist). Mit diesem Timer-Interrupt läßt sich nun eine Interruptroutine ansteuem, 
die mitzählt, wie oft der Abwärtszähler während des Ein-Pegels an TAI (oder TBI) (= Dauer 
des Ereignisses) komplett heruntergezählt wurde. 

DieGesamtzahlderZählimpulse(unddamitdieEreignisdauer),flirdiederTimer“Ein”geschaltet 
war, ist damit wie folgt zu berechnen: 

(Zahl der Timer-Interrupts x Anfangswert des Timer-Data-Registers) 
plus (Differenz aus Anfangs- und Endwert im Timer-Data-Register) 


Betrieb als Ereigniszähler 

Die Timer A und B kennen noch eine weitere Betriebsart, den Event-Count-Mode. Dabei wird 
mit den Timern jedoch keine Zeit mehr gemessen, sondern die Zahl von aufgetretenen Ereig¬ 
nissen gezählt. 

Hierfür werden, wie bei der Pulsbreitenmessung, die Timer-Eingänge TAI bzw. TBI benötigt. 
Die Interrupts 14 bzw. 13 des MFP reagieren auch hier wieder nicht auf die Signale an den 
Parallel-PortsI4bzw. 13 des MFP, sondern, wie bei derPulsbreitenmessung, auf Flankenwechsel 
an den TAI- bzw. TBI-Anschlüssen. Beim Betrieb als Ereigniszähler sind die Vorteiler A bzw. 
B jedoch nicht aktiviert (es sollen ja auch keine Zeitimpulse gezählt werden!). 

Der Abwärtszähler im Timer erhält also seinen Zählimpuls nicht mehr vom Vorteiler, sondern 
direkt durch einen Pegelwechsel am TAI- bzw. TBI-Anschluß! Jeder Zählimpuls erniedrigt 
den Abwärtszähler im Timer um 1. Hat der Abwärtszähler einen Zählerstand von 1 erreicht, 
so wird durch den nächsten Impuls an TAI bzw. TBI der Timerausgang TAO bzw. TBO seinen 
Pegel ändern und ein entsprechender Timer A-bzw. Timer B-Interrupt ausgelöst, wenn dieser 
freigegeben ist. Außerdem wird der Abwärtszähler des Timers wieder neu mit dem Startwert 
aus dem Timer A- bzw. Timer B-Data Register geladen. 
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Ob der Zählimpuls für den Abwärtszähler bei einem Low/High- oder Higb/Low-Übergang am 
Timereingang erzeugt wird, läßt sich auch hier wieder durch Setzen bzw. Löschen des Bit 4 
bzw. Bit 3 im Aktiv-Edge-Register (Label “AER” an Adr. $FF FA03) festlegen. 

Ein gesetztes Bit 4 bzw. Bit 3 bedeutet, daß ein Zählimpuls erzeugt wird, wenn an TAI bzw. 
TBI ein Pegelwechsel von Low->High erfolgt. Bei gelöschtem Bit wird ein Zählimpuls bei 
High/Low-Wechsel des Timereingangs erzeugt. Außerdem wird mit jedem erzeugten Zähl¬ 
impuls ein Interrupt für den entsprechenden Interruptkanal 13 bzw. 14 erzeugt (sofern zugelas¬ 
sen). Es ist aber sinnvoll, den Interrupt für den entsprechenden TAI- bzw. TBI-Anschluß zu 
sperren. Das Zählen der Ereignisse (Low/High- bzw High/Low-Pegel Wechsel) am Timereingang 
könnte ja sonst gleich durch die Interrupt-Routine erfolgen und nicht durch den Abwärtszähler 
im Timer! 


Timer B als Bildschirmzeilenzähler 

Im ST liegt am TBI-Anschluß des MFP das Signal Display-Enable an. Dieses Signal geht so 
lange auf High, wie eine Bildschirmzeile geschrieben wird. So läßt sich mittels Ereigniszähler 
z. B. nach Ablauf einer programmierten Zahl von Bildschirmzeilen ein Interrupt auslösen, um 
dann eine Display-Manipulation durchzuführen. 


Die Timer-Register 

Die Programmierung der vier Timer erfolgt über vier 8 Bit breite Timer-Data-Register und 
drei 8 Bit breite Timer-Control-Register. Timer A und B besitzen je ein eigenes Control- 
Register. Für die Steuerung von Timer C und D reicht ein gemeinsames 8-Bi t Control Register 
aus, da diese Timer ja nur eine Betriebsart, den Delay Mode, kennen. 

Adresse Zugriff Funktion des Registers Label 


$FFFA1F R/W Timer-A-Data-Register “TADR” 

Beim Auslesen erhält man den augenblicklichen Zählerstand des 
Timers A. Wird ein Wert in das Register geschrieben, so gelangt 
dieser gleichzeitig in den Abwärtszähler. Dies gilt jedoch nur für 
den Fall, daß der Timer gestoppt ist! 

“Läuft” dagegen gerade ein Zählvorgang, so gelangt der neu 
eingeschriebene Wert erst in den Abwärtszähler des Timers, 
wenn dieser durch 1 zählt. 



Der Multifunktionsbaustein MPP 68901 


879 


Adresse Zugriff Funktion des Registers 


Label 


$FF FA21 RAV 


$FF FA23 RAV 

$FF FA25 RAV 

$FF FA 19 RAV 


Timer-B-Data-Register “TBDR” 

Funktion wie bei Timer A für Timer B. 

Timer-C-Data-Register “TCDR” 

Funktion wie bei Timer A für Timer C. 

Timer-D-Data-Register “TDDR” 

Funktion wie bei Timer A für Timer D. 

Timer-A-Control-Register “TACR” 

Bit 0..3 dieses Registers bestimmen Betriebsart des Timers A 
und Teilerverhältnis von Vorteiler A. Bits 5..7: keine Funktion. 


Bit-Nr. 

3210 

Funktion 

0000 

Timer gestoppt (*) 


0001 

Delay Mode, Vorteiler auf 

1:4 

00 10 

Delay Mode, Vorteiler auf 

1:10 

00 1 1 

Delay Mode, Vorteiler auf 

1:16 

0100 

Delay Mode, Vorteiler auf 

1:50 

0 10 1 

Delay Mode, Vorteiler auf 

1:64 

0 110 

Delay Mode, Vorteiler auf 

1:100 

0 111 

Delay Mode, Vorteiler auf 

1:20p 

1000 

Ereigniszählung 


1001 

Pulsbreitenmessung, Vorteiler auf 

1:4 

10 10 

Pulsbreitenmessung, Vorteiler auf 

1:10 

10 11 

Pulsbreitenmessung, Vorteiler auf 

1:16 

1 100 

Pulsbreitenmessung, Vorteiler auf 

1:50 

1101 

Pulsbreitenmessung, Vorteiler auf 

1:64 

1110 

Pulsbreitenmessung, Vorteiler auf 

1:100 

1111 

Pulsbreitenmessung, Vorteiler auf 

1:200 


(*)= Zählvorgang wird unterbrochen. Der Inhalt des Timer-A-Abwärtszählers bleibt erhal¬ 
ten. Wird jetzt ein neuer Wert ins T imer-A-Data-Register geschrieben, so gelangt dieser auch 
sofort in den Abwärtszähler! 
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Adresse Zugriff Funktion des Registers 


Label 


Ist durch Einschreiben in das Register das Bit 4 gesetzt, geht der 
Timer-A-Ausgang auf Low-Pegel und bleibt für die Dauer der 
Schreiboperation Low, 

Danach kann der Ausgang abhängig vom Zählvorgang (Ab¬ 
wärtszählen durch 1) wieder seinen Zustand wechseln. 

SFFFAlB RAV Timer-B-Control-Register “TBCR” 

Die Funktion und Bitbelegung ist die gleiche wie für das Timer- 
A-Control-Register. 

$FFFA1D RAV Timer-C/D-Control-Register “TCDCR” 

Die Teilerverhältnisse für die Vorteiler C + D werden durch 
dieses Register kontrolliert. Die Bits 0..2 steuern Timer D, die 
Bits 4..6 den Timer C. 


Bit-Nr. 

6 5 4 (C) oder 

2 1 0 (D) 

Funktion 

000 

Timer gestoppt (*) 


001 

Delay Mode, Vorteiler 

1:4 

0 1 0 

Delay Mode, Vorteiler 

1:10 

01 1 

Delay Mode, Vorteiler 

1:16 

1 00 

Delay Mode, Vorteiler 

1:50 

101 

Delay Mode, Vorteiler 

1:64 

1 1 0 

Delay Mode, Vorteiler 

1:100 

111 

Delay Mode, Vorteiler 

1:200 


(*)= Zählvorgang wird unterbrochen. Der Inhalt des Timer-Abwärtszählers bleibt erhalten. 
Wird jetzt ein neuer Wert ins Timer-Data-Register geschrieben, so gelangt dieser auch sofort 
in den Abwärtszähler! 


Achtung bei der Timerprogrammierung 

Bei der Timerprogrammierung sollte man sich vorher schon genau im klaren sein, was man 
erreichen will und wie der Timer sich verhalten soll. So muß man z. B. mit falschen Ergebnis- 
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sen rechnen, wenn das Vorteilerverhältnis geändert wird, während der Timer “läuft”. Weiter¬ 
hin können in der Betriebsart “Pulsbreitenmessung” und “Ereigniszählung” Interrupts auftre- 
ten, wenn man die Flankenbits im Active-Edge-Register ändert, während der Timer arbeitet. 

Bei der Betriebsart “Pulsbreitenmessung” sollte man auch darauf achten, daß einem nicht der 
Timer schon wieder neu gestartet wird (durch Ein-Pegel am Timer-Eingang), bevor man den 
Wert im Abwärtszähler für eine neue Messung initialisiert hat. Im Betriebssystem des ST ist 
für das Setzen der Timerregister des MFP ein eigener XBIOS-Aufruf vorgesehen (siehe 
XBIOS-Funktion #31, “Xbtimer”). Damit wird die Timerprogrammierung wesentlich verein¬ 
facht. 

Bevor nun auf die Interrupt-Bearbeitung des MFP eingegangen wird, zunächst einige 
Erläuterungen zur Intenruptbehandlung durch die 68000er CPU. 


Interrupt-Steuerung 

Die im ST verwendete 68000er-CPU besitzt “von Haus aus” die Möglichkeit, Unterbrechun¬ 
gen (Interrupts) sieben verschiedene Prioritäten (Interrupt-Level) zuzuordnen. 

Interrupts des Level 7 besitzen höchste Priorität und sind auch nicht maskierbar, d. h., sie 
können wiederum durch einen Interrupt der Priorität 7 unterbrochen werden, 

Die Interrupt-Level 1 ..6 sind maskierbar und können bei entsprechender Programmierung der 
Unterbrechungsmaske in der CPU (Bits 8.. 10 im Supervisor-Status-Register) nur durch einen 
höher priorisierten Interrupt unterbrochen werden. 

Ein in Bearbeitung befindlicher Interrupt setzt die Unterbrechungsmaske dabei automatisch 
auf seinen Interrupt-Level, d. h., er kann nur durch einen Interrupt höherer Priorität unterbro¬ 
chen werden. 

Der Level 0 bedeutet, daß keine Interrupt-Anforderung gestellt wurde. 


Interrupt-Prioritäten im ST 

Die Interrupt-Priorität der unterbrechenden Einheit wird der CPU über drei Interrupt-Priority- 
Levei-Anschlüsse IPL0..IPL2 (low-aktiv) “mitgeteiit”. Im ST liegt die Leitung IPL0 jedoch 
fest auf High, so daß nur die Interrupt-Ebenen 2,4 und 6 existieren (Beim MEGA-ST sind die 
Interrupts 3,5 und 7 auch möglich. Sie können jedoch nur über Anschlüsse am Megabus ausge¬ 
löst werden. Siehe auch Teil II, Kapitel 1, “Die Zentraleinheit”). 
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Die Interrupt-Ebene 2 wird im ST durch den Horizontal-Blanking-Interrupt (HBLANK- 
Interrupt) belegt. Dieser Interrupt tritt immer dann auf, wenn eine Bildschirmzeile geschrieben 
wurde und der Elektronenstrahl im Monitor für den Strahlrücklauf zum Anfang einer neuen 
Zeile dunkelgetastet (ge”blanked”) wird. Um jedoch zu vermeiden, daß ein laufendes Pro¬ 
gramm durch jeden Horizontal-Blankingimpuls unterbrochen und damit verlangsamt wird, ist 
die Unterbrechungsmaske der CPU im ST im Normalfall auf 3 gesetzt. Der HBLANK-Inter- 
rupt ist somit maskiert und wird nicht ausgeführt. 

Die bei der Systeminitialisierung installierte HBLANK-Interrupt-Routine macht nichts 
anderes, als die Unterbrechungsmaske in der CPU auf 3 zu setzen, um weitere auftretende 
HBLANK-Interrupt-Anforderungen unwirksam zu machen. 

Programmierer, die sich den HBLANK-Interrupt zunutze machen wollen, um z. B. die Farb- 
registerinhalte zwischen zwei Bildschirmzeilen zu ändern, sollten darauf achten, daß zwi¬ 
schen zwei HBLANK-Interrupts nur 64 pSek. (28 jrSek. in Monochrom-Betriebsart) liegen. 
Die Interruptroutine hat also nicht viel Zeit, um ihre Aufgabe zu erledigen. Wenn dann noch 
der Systemtimer-Interrupt “dazwischenrutscht” (Timer C “interrupted” alle 5 msec.), kann es 
zu einer zitternden, unruhigen Bildschirmdarstellung kommen. 

Man kann sich mit dem Systemtimer-Interrupt jedoch dadurch helfen, indem man für die Zeit, 
in der mit HBLANK-Interrupts gearbeitet wird, den Interruptvektor für den Systemtimer zu 
einer ganz kurzen Routine umleitet, die nichts anderes macht, als die zwischenzeitlich 
auftretenden Systemtimer-Interrupts zu zählen. 

Sind die HBLANK-Interrupts dann wieder gesperrt, so blockiert man zunächst durch ent¬ 
sprechende Maskierung (Interrupt-Priority-Level auf 6) in der CPU alle weiteren Interrupts. 
Dann wird die Interrupt-Routine für den Systemtimer so oft aufgerufen, wie dieser Interrupt 
während der “kritischen” Zeit aufgetreten ist (die Anzahl der Aufrufe wurde ja in der kleinen 
Systemtimer-Interrupt-”Hilfsroutine” mitgezählt). 

Die Interrupt-Ebene 4 ist für den Vertical-Blank-Interrupt (VBLANK-Interrupt) reserviert. 
Dieser Interrupt tritt in der Monochrom-Betriebsart alle 14 mSek. und in der Color-Betriebsart 
alle 20 mSek. auf. Zu weiteren Einzelheiten bezüglich dessen Aufgabe siehe Teil I, Kapitel 
1, “Der Vertical Blank Händler”. 


Selbstgemachte Interrupt-Vektornummern 

Sowohl bei dem HBLANK- als auch dem VBLANK-Interrupt handelt es sich um einen 
sogenannten Autovektor-Interrupt. Bei so einem Interrupt erzeugt die CPU intern, sozusagen 
“automatisch”, eine Inteirupt-Vektomummer. Diese Autovektor-Nummer ergibt sich dabei 
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aus der Priorität des Interrupts. Daß ein Autovektor-Interrupt aufgetreten ist, erfährt die CPU 
durch ein Low über den VPA-Anschluß (Valid-Peripheral-Address) während der Phase der 
Unterbrechungsanerkennung. Aus dieser Autovektor-Nummer wird dann die Interrupt- 
Vektor-Adresse berechnet (Autovektor-Adresse=Autovektomummer * 4). Unter der Interrupt- 
Vektor-Adresse findet die CPU dann einen Zeiger auf die abzuarbeitende Interruptroutine, die 
dann aufgerufen wird. 

Für Interrupts der Priorität 2 (IIBLANK-Interrupt) wird eine Vektomummer von 26 erzeugt. 
Der Zeiger auf die HBLANK-Interrupt-Routine befindet sich also an Adresse $68. Der 
VBLANK-Interrupt (Priorität 4) erzeugt die Vektomummer 28. Die Interrupt-Vektor-Adres¬ 
se lautet somit auf $70. 


Interrupts durch den MFP-Baustein 

Ein Interrupt, der durch den MFP ausgelöst werden kann, liegt auf Level 6, hat also im ST 
nahezu höchste Priorität. Im MFP-Baustein selbst werden nochmals 16 Interruptkanäle unter¬ 
schieden, denen MFP-intem 16 verschiedene Prioritäten zugeordnet sind. Wie die folgende 
Tabeile zeigt, hat z. B. der Interrupt des I/O-Port 7 (17, Monochrom-Monitor-Detect) im MFP 
höchste Priorität. Das BUSY-Signal (10) der parallelen Schnittstelle würde,wäre der Interrupt 
im ST aktiviert, dagegen einen Interrupt niedrigster Priorität bei der MFP-Logik auslösen. 


Kanal 

Hp. : 

Interrupt durch 

Bedeutung in "ST" 

i 13 

I/O—Purt 7 £173 

Honochron Monitor Detect 

1 « 

I/O-Port: 6 £IB3 

RI von ser. Schnittstelle 

e 13 

T iner A 

nicht benutzt 

r 12 

RCU Buffer full 

ser. Schnittstelle Enofängerpuffer voll 

11 

RCU Error 

ser. Schnittstelle Enpfangsfehler 

** 10 

XMIT Buff, enpty 

ser. Schnittstelle Sendepuffer leer 

¥ 9 

XMIT Error 

ser. Schnittstelle Sendefehler 

e 8 

Tiner B 

Display Enable-Signal Zähler 

7 

I/O-Port 5 (133 

FDC-Readg/ACSI-Bus Steuerung 

t 6 

I/O-Port: 4 (143 

IRß von Tastatur/MIDI-ACIA*s 

5 

Tiner C 

208 Hz Systentakt 

.2 4 

Tiner D 

ser. Schnittstelle Baudraten-Generator 

£ 3 

X/O-Port 3 £133 

£BPU-Pone Signal von Blitter-Chip3 

.S 2 

t/Q-Port 2 C123 

CTS von ser. Schnittstelle 


I/O—Port 1 £113 

DCD von ser. Schnittstelle 

1 a 

I/O-Port 0 £103 

BUSV von par. Schnittstelle 


Abb. 4.4: So sind die Interrupt-Kanäle des MFP intern gewichtet 
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Non-Autovektor-Interrupts 

Der MFP erzeugt bei der CPU im ST einen “Non-Autovektor-Interrupt”, d. h., nicht die CPU 
bildet eine Vektomummer, aus der dann die Lage des Interruptvektors im Speicher bestimmt 
wird, sondern der MFP-Baustein sendet, nachdem seine Unterbrechungsanforderung von der 
CPU bestätigt wurde, eine “eigene” Vektomummer zur CPU. Die CPU “erfährt” von einem 
Non-Autovektor-InterruptdurcheinLowamDTACK-Anschluß(Data-Transfer-Acknowledge) 
während der Interrupt-Anerkennungsphase. 



Abb. 4.5; Das Prinzip der Interrupt-Bearbeitung CPU<->MFP 
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Aus dieser vom MFP gelieferten Vektomummer berechnet die CPU dann die Speicheradresse, 
in der ein Zeiger auf den Anfang der Interrupt-Routine steht. Beim ST liegen diese 16 Zeiger 
(Unterbrechungsvektoren) für MFP-Interrupts ab Adresse $ 100 im Supervisorspeicherbereich. 
Es sind jedoch vom Betriebssystem nicht alle 16 Interruptkanäle des MFP aktiviert. 

Beispielweise sind alle I/O-Port 0..3 (I0..I3)-Interrupts des MFP gesperrt, weil diese I/O- 
Anschlüsse nicht per Interrupt bedient werden, sondern evtl, durch einfaches “Polling”. Das 
bedeutet nichts anderes, als daß vom Betriebssystem in einer Schleife oder nach Ablauf einer 
bestimmten Verzögerung der Zustand dieser als Eingang eingestellten Ports abgefragt wird. 

So erfolgt z. B. die Zeichenausgabe an den Drucker über die parallele Schnittstelle nicht 
interruptgesteuert, sondern per Polling. Jedesmal wenn ein Zeichen an den Drucker gesendet 
werden soll, wird “nachgeschaut”, ob BUS Y (I/O-Port 0) noch auf High liegt. Ist der Drucker 
noch BUSY (BUSY auf High), so wird eine Schleife durchlaufen, in der fortlaufend der Zu¬ 
stand der BUSY-Leitung abgefragt wird (Polling). Erst wenn BUSY auf Low geht, gelangt 
das auszugebende Zeichen an die parallele Schnittstelle. 

Es wird jedoch vom Betriebssystem eine “Time out”-Überwachung mittels Systemtimer 
(Timer C des MFP) durchgeführt, damit spätestens nach ca. 30 Sek. erfolglosen “Wartens auf 
BUSY” mit einer Fehlermeldung ins aufrufende Programm zurückgekehrt werden kann. 

Bei einem nicht angeschlossenen Drucker oder wenn dieser “Offline” geschaltet ist, würde 
man sonst ewig (na ja, bis zum RESET) warten müssen. 


Adresse 

MFP~Int. 
Hunnen t 

Status 

zeigt auf Interrupt-Routine für* 

Interrupt durch 

5100 

0 

gesperrt 

BUSV-Anschluß der par. Schnittst. 

I/O-Port 8 (IB) 

5104 

1 

gesperrt 

DCD~Signal serielle Schnittstelle 

I/O-Port 1 CI1) 

5100 

2 

gesperrt 

CTS-Signal serielle Schnittstelle 

I/O-Port 2 (12) 

S10C 

3 

gesperrt 

IGPU-Done Signal vom Blitter Chip) 

I/O-Port 3 (13) 

S11B 

4 

gesperrt 

Baudraten-Gen. ser. Schnittstelle 

Tiner D 

5114 

5 

aktiv. 

200 Hz Systen Tiner 

Tiner C 

5118 

G 

aktiv. 

Tastatur/MIDI (ACIA) Bedienung 

IZO-Port 4 (14) 

S11C 

7 

gesperrt 

FDC-Ready/ACSI~Bus Steuerung 

I/O-Port 5 (15) 

5120 

8 

gesperrt 

Display Enable Signal CHor.Sync.J 

Tiner B 

5124 

9 

aktiv. 

Sendefehler ser. Schnittstelle 

XMIT-Error 

5128 

10 

aktiv. 

Sendepuffer leer Cser. Interface) 

XMIT-Buf, enpty 

S12C 

11 

aktiv. 

Enpfangsfehler tser. Interface) 

RCU-Error 

5130 

12 

aktiv v 

Enpfangspuffer voll Cser. Interf) 

RCU-Buffer full 

5134 

13 

gesperrt 

nicht benutzt 

Tiner A 

5138 

14 

gesperrt 

Rl-Signal serielle Schnittstelle 

I/O-Port 6 (IG) 

S13C 

15 

gesperrt 

Monochroh Monitor Dete'ct 

I/O-Port 7 (17) 


Abb. 4.6: Die Lage der MFP-Interrupt-Vektoren im ATARI ST-RAM 
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Einer der aktivierten Interrupts ist jener für den schon mehrfach erwähnten 200 Hz- 
Systemtimer, der eine Art “innere Uhr” im ST darstellt und unter anderem fürTastenwiederholung 
und als Takt für den “Pseudo-Soundprozessor” benutzt wird. 

Aktiviert ist auch der Interrupt für die beiden ACIAs, welche zur Kommunikation mit der 
Tastatur und der MIDI-Schnittstelle dienen. Es muß ja gewährleistet sein, daß Informationen 
von der “Intelligenten Tastatur”, wie Tasten- oder Mausbetätigungen, laufend ans Betriebs¬ 
system weitergegeben werden. Die Interrupts zur Bedienung des Sende- und Empfangsteils 
der seriellen Schnittstelle des MFP sind ebenfalls aktiviert. 


Mit drei Steuerregistern die MFP-Interrupts im Griff 

Zur Interrupt-Bearbeitung besitzt der MFP drei Steuerregister, die jeweils 2 * 8 Bit breit sind. 


ftdressa. 


SFF FA07 
*IERA' 

Port 

* 17 

Port 

* 16 

Tifter 

fi 

RCU 

Buffer 

full 

RCU 

Error 

XMIT 

Buffer 

ertpty 

XMIT 

Error 

Ti«en 

B 

-X 

Bit 

7 

8 

5 

4 

3 

2 


0 

SFF FA09 

Port 

Port 

Tirier 

Titter 

Port 

Port 

Port 

Port 

1 IERB 1 

15 

£_ 

14 

c 

D 

13 

* 

13 

-K 

I 1 

10 


Interrupt 
Enable 
Register ft 


Interrupt 
Enable 
Register B 


* = Diese Interrupts sind in ST gesperrt! 


Alle 16 möglichen Interruptkanäle des MFP können einzeln ein- bzw. ausgeschaltet werden. 
Die MFP-Logik registriert nur Interrupts von Kanälen, die auch eingeschaltet sind, und gibt 
diese dann in Form von Unterbrechungsanforderungen an die CPU weiter. Ausgeschaltete 
Interruptkanäle werden nicht beachtet. Durch Setzen des entsprechenden Bits im IERA (Inter- 
rupt-Enable-Register A) oder IERB wird der zugehörige Interruptkanal eingeschaltet. 


Adresse 
SFF FA0B 
■ IPRfl' 

Bit 
SFF FA0D 
'IPRB" 


Port 

17 

Port 

16 

Tiwer 

ft 

RCO 

Buf fe-r 
Pull 

RCU 

Error 

XMIT 

Buffer 

empty 

XMIT 

Error 

Tirter 

B 

7 

6 

5 

4 

3 

2 

i 

0 

Port 

Port 

Titter 

T i«er 

Port 

Port 

Port 

Port 

15 

14 

c 

D 

13 

13 

I 1 

10 


Interrupt 

Pending 

Register 


ft 


Interrupt 
Pending 
Register B 


Jedem Interruptkanal des MFP ist ein Bit im Interrupt-Pending-Register A oder B (IPRA oder 
IPRB) zugeordnet. Empfängt die MFP-Logik einen Interrupt von einem aktivierten Interrupt- 
Kanal, so wird das zugehörige Bit gesetzt. Dieser Interrupt wird so lange als noch nicht aner¬ 
kannt = “schwebend” (pending) geführt, bis die Unterbrechungsanforderung von der CPU be¬ 
stätigt wird. 
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Im “Non-Autovektor'Intemipt”-Betrieb des MFP, wie es im ATARI ST der Fall ist, wird ein 
gesetztes Bit im IPRA oder IPRB erst dann gelöscht, wenn die CPU den Interrupt für den 
entsprechenden Kanal bestätigt hat und der MFP die zugehörige Vektomummer an die CPU 
sendet. 

Die IPRA und IPRB können von der CPU jederzeit gelesen und beschrieben werden. Es ist 
auch möglich, Bits des IPRA oder IPRB per Software (durch Programmbefehl) zu löschen. 
Dazu muß für alle jene Bits, welche nicht gelöscht werden sollen, eine “1 ” in das Register ge¬ 
schrieben werden. 


Die zu löschenden Bits werden als “0” geschrieben. Gelöschte Bits können jedoch nicht wieder 
durch Beschreiben mit einer “ 1 ” gesetzt werden! Das ist nur durch Auslösung eines Interrupts 
möglich. Der Wert im Interrupt-Pending-Register wird also mit dem einzuschreibenden Wert 
UNDiert und das Resultat im Register abgelegt. 

Einzelne Bits im IPRA bzw. IPRB werden auch dann gelöscht, wenn die zugehörigen Inter¬ 
rupt-Kanäle im Inteirupt-Enable-Register A bzw. B gesperrt werden. 


Adresse 


$FF FA13 
■IMRA" 

Port 

17 

Port 

16 

Tirter 

fl 

RCO 

Buffer 

full 

RCV 

Error 

XMIT 

Buffer 

empty 

XMIT 

Error 

T imer 

B 

Bit 

! 1 

8 

5 

4 

3 

2 

1 

0 

SFF FA15 

Port 

Port 

Tiws-r 

Tiwer 

Port 

Port 

Port 

Port 

•IMRB 1 

IS 

14 

c 

D 

13 

12 

11 

I 0 


Interrupt 

Mask 

Register A 


Interrupt 

Mask 

Register B 


Mit Hilfe der Interrupt-Mask-Register A bzw. B (IMRA bzw. IMRB) ist es möglich, bestimm¬ 
te Interruptkanäle des MFP zu maskieren (auszublenden). 

Ist ein Interrupt-Kanal zwar aktiviert, aber maskiert, so wird eine evtl. Interruptsignalisierung 
zwar von der MFP-Logik registriert und das zugehörige “Pending”-Bit im IPRA bzw. IPRB 
gesetzt. Es wird jedoch keine Interrupt-Anforderung für diesen Kanal an die CPU gesendet. 

Die Maskierung eines Interrupt-Kanals erfolgt durch Löschung des zugehörigen Bits. Durch 
Setzen eines Bits wird die Maskierung für den zugehörigen Kanal aufgehoben. 

Signalisiert ein maskierter Kanal einen Interrupt zur MFP-Logik, so wird das entsprechende 
Bit des IPRA bzw. IPRB gesetzt (pending Interrupt). Nach Beendigung der Maskierung wird 
durch das gesetzte IPRA- bzw. IPRB-Bit die MFP-Logik nun bei der CPU einen Interrupt für 
diesen, nun nicht mehr maskierten, Kanal anfordem. Die Interrupt-Mask-Register können 
jederzeit beschrieben und ausgelesen werden. 
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Die im folgenden beschriebenen Register dienen weniger der Steuerung als der Signalisierung 
von MFP-Interrupts. 


Adresse 
SFF FA17 
■MR* 


|V7|U6 

|U5|U4| s iXIXIXI 





End-of-Interrupt Modus Bit 
High-Nibble der Vektornunner 


Wie bereits erläutert, sendet der MFP im “Non-Autovektor-Interrupt”-Modus nach Bestäti¬ 
gung der Interrupt-Anforderung durch die CPU eine dem MFP-Interrupt-Kanal entsprechende 
8-Bit-Vektomummer an die CPU, damit diese daraus die Adresse des zugehörigen Interrupt- 
Vektors berechnen kann. Und so ist diese Vektomummer aufgebaut: 

- Die unteren vier Bits (Low-Nibble) der 8-Bit-Vektomummer stellen die Nummer des 
Interrupt-Kanals (0...15) im MFP dar, der den Interrupt ausgelöst hat. 

- Die oberen vier Bits (High-Nibble) der Vektomummer werden von der MFP- Logik aus 
dem Interrupt-Vektor-Register entnommen. Es handelt sich dabei um eine Kopie der 
oberen vier Bits dieses Registers. Im ST ist hierbei ein Wert von “0100” für die Bits 7..4 
initialisiert. 

Der MFP im ST kann somit mit seinen 16 Interrupt-Kanälen die Vektomummem “0100 0000” 
(dez. 64) bis “0100 1111” (dez. 79) erzeugen. 

Das S-Bit stellt denEnd-of-Intermpt-Modus (EOI-Modus) ein. Bei gelöschtem Bit arbeitet der 
MFP im Automatic-EOI-Modus. Der Software-EOI-Modus ist bei gesetztem S-Bit aktiviert. 
Näheres zum EOI-Modus folgt nun bei der Beschreibung des Interrupt-in-Service-Registers. 

Adresse 
SFF FA8F 
■ISRA 1 

Bit 
SFF FAII 
'ISRB * 


Port 

17 

Port 

16 

Tirten 

fl 

ftCU 

Buffer 
full 

RCV 

Error 

XMIT 

Buffer 

ertpty 

XMIT 

Error 

Titter 

B 

: 7 

6 

5 

4 

3 

2 

1 

0 

Port 

Port 

T irten 

Ti«er 

Port 

Port 

Port 

Port 

IS 

14 

C 

D 

13 

13 

11 

10 


Interrupt 
in-Service 
Register A 


Interruot 
in-Service 
Register B 


Dieses Register ist nur von Bedeutung, wenn das S-Bit im Interrupt-Vektor-Register gelöscht 
ist. Der MFP arbeitet dann im Software-EOI-Modus. Im Software-EOI-Modus muß die CPU 
der MFP-Logik durch einen Befehl das Ende der Interrupt-Bearbeitung für den zur Zeit 
bearbeiteten Interrupt mitteilen. Dieser Modus wird im ST benutzt. 
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Die Interrupt-Bearbeitung läuft folgendermaßen ab (es soll noch keine Interrupt-Anforderung 
vorliegen): 

- Ein aktivierter Kanal meldet der MFP-Logik einen Interrupt. 

- Das zugehörige Bit im Interrupt-Pending-Register wird gesetzt. Der MFP sendet eine 
Interrupt-Anforderung an die CPU. 

- Die CPU bestätigt die Anforderung, und der MFP sendet der CPU die entsprechende Vek- 
tomummer. Gleichzeitig wird das zugehörige Interrupt-Pending-Bit gelöscht. 

Dafür wird im Intermpt-in-Service-Register A bzw. B das zugehörige Bit gesetzt. Der 
Interrupt wird bearbeitet (der Interrupt ist “in-Service”). 

- Die laufende Interrupt-Bearbeitung für diesen Kanal kann nur durch einen Interrupt eines 
höherwertigen Kanals unterbrochen werden. 

- Interruptsignalisierungen von niedriger priorisierten Kanälen werden zwar von der 
MFP-Logik registriert (Setzen des entspr. Bits in IPRA bzw. IPRB), fuhren aber nicht 
zu einer Unterbrechungsanforderung an die CPU. 

Weil das Interrupt-Pending-Bit für den gerade in Bearbeitung befindlichen Interrupt ja 
wieder gelöscht wurde (aufgrund der Interrupt-Bestätigung durch die CPU), kann schon 
wieder eine neue Interruptsignalisierung für diesen Kanal von der MFP-Logik registriert 
werden (Setzen des Interrupt-Pending-Bits). Aber auch hier wird der laufende Interrupt 
nicht unterbrochen. 

- Nach Beendigung des laufenden Interrupts muß durch die CPU das zugehörige Bit im 
Interrupt-in-Service Register A bzw. B gelöscht werden. Ein Bit wird gelöscht, indem 
alle Bits des Registers, bis auf das zu löschende Bit, mit “1 ” beschrieben werden. Da Bits 
im hiterrupt-Pending-Register per Software nur gelöscht und nicht gesetzt werden kön¬ 
nen, werden Registerinhalte durch das Beschreiben mit “1” nicht geändert. 

- Erst nach Löschung des Interrupt-in-Service-Bits für den gerade beendeten Interrupt 
kann die MFP-Logik wieder Interrupt-Anforderungen für bereits signalisierte (Bits im 
IPRA od. IPRB gesetzt) Interrupts an die CPU stellen. 

Im Automatic-EOI-Modus bleibt das Interrupt-in-Service-Register ohne Funktion. Auch hier 
wird nach Bestätigung der Interrupt-Anforderung durch die CPU das entsprechende Interrupt- 
Pending-Bit gelöscht. Nachfolgend auftretende Interrupts irgendeines Kanals des MFP (und 
damit jeglicher Priorität) führen zu einer Interrupt-Anforderung an die CPU, egal ob die 
laufende Interrupt-Bearbeitung beendet ist oder nicht. 
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Wie schon für die Timer des MFP sind im Betriebssystem des ST Funktionen für die Be¬ 
handlung der MFP-Interrupts vorgesehen. Siehe hierzu im Teil I, Kapitel 1, “XBIOS-Refe¬ 
renz”, die XBIOS-Funktionen #13 (“Mfpint”), #26 (“Jdisint”) und #27 (“Jenabinf’). 


So ein kleiner Chip - und doch so viele Möglichkeiten 

Wie man sieht, ist der MFP-Chip im ST mit einer ganzen Reihe von Aufgaben betraut. 

Einige wenige Anschlüsse und Funktionen sind, wie bereits vorher erwähnt, noch nicht 
benutzt. Hier bieten sich dem hardwarenahen Programmierer und dem engagierten Hobby- 
Elektroniker noch einige Möglichkeiten, eigene Vorstellungen zu verwirklichen. 



891 


Kapitel 5: Die serielle Schnittstelle 


Wie der Name schon sagt, werden mit Hilfe der seriellen Schnittstelle Daten Bit für Bit 
nacheinander (seriell) über einen Übertragungs weg ausgetauscht. Ein gesetztes Bit wird dabei 
durch einen log. H-Pegel und ein gelöschtes Bit somit durch einen log. L-Pegel dargestellt. 
Für jedes Bit wird also auf die Übertragungsleitung für eine bestimmte Zeiteinheit ein dem 
Zustand des Bits entsprechender log. Pegel angelegt. 

Die serielle Schnittstelle des ST lehnt sich dabei an den RS-232C-Standard an. Die Spannungs¬ 
pegel entsprechen den Vereinbarungen: 

Log. L= “Ein”-Zustand = +3V..+15V 

Log. H = “Aus”-Zustand = -3V..-15V 

Mit dem im ST für die Steuerung der seriellen Schnittstelle zuständigen Chip ist sowohl 
synchrone als auch asynchrone Datenübertragung möglich. Leider kann aber das synchrone 
Gleichlaufverfahren nicht benutzt werden, da die dazu erforderlichen Taktleitungen nicht am 
Schnittstellenanschluß zur Verfügung stehen! 

Nachfolgend eine kurze Erläuterung zu diesen beiden Gleichlaufverfahren. 


Synchrone Betriebsart 

Bei synchroner, serieller Übertragung arbeiten die beteiligten Datenübertragungseinheiten 
(Sende- und Empfangseinheit) ständig exakt im gleichen Takt (synchron). Dazu ist eine 
genaue Übereinstimmung zwischen Sender- und Empfängertakt erforderlich. An der Schnitt¬ 
stelle zum Datenübertragungsgerät sind deshalb Leitungen für den Sende- und Empfangstakt 
erforderlich. 

Durch die zusätzlich vorhandenen Taktleitungen ist gewährleistet, daß bei einer Datenübertra¬ 
gungsverbindung beide Seiten bitsynchron arbeiten! Also sind beide Seiten auch synchron, 
wenn gar keine Nutzdaten übertragen werden. Damit die Gegenstelle “merkt”, daß nun Nutz¬ 
daten übertragen werden und wo diese Zeichen beginnen, muß sie das an bestimmten Marken 
im Bitstrom erkennen können. 

Dazu wird das sogenannte Synchronzeichen verwendet. Es dient dazu, die Empfangsstelle in 
die Zeichensynchronisation zu bringen. Sende- und Empfangseinheit müssen natürlich die 
“gleiche Sprache sprechen” (das gleiche Synchronzeichen benutzen). 
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Einesy nchrone Datenübertragung beginnt immer mit der Aussendung eines Synchronzeichens. 
Die Empfangseinheit “sucht” zunächst im empfangenen seriellen Bitstrom nach dem typi¬ 
schen Bitmuster des vereinbarten Synchronzeichens. Dabei werden, je nach Vereinbarung, 
zum Start der Übertragung ein oder zwei Synchronzeichen gesendet. Erst wenn von der Emp¬ 
fangseinheitein (oder zwei) Synchronzeichen erkannt wurde(n), “rastet” diese ein und beginnt 
die nachfolgenden seriellen Daten im so gefundenen Rhythmus zu decodieren. 


Asynchrone Betriebsart 

Die (in der ST/PC-Welt) geläufigere Art der seriellen Datenübertragung und deshalb vom TOS 
standar dmäßig unterstützt, ist die asynchrone Betriebsart. Asynchron deshalb, weil nur für die 
Dauer eines Zeichens Gleichlauf zwischen Sender und Empfänger herrschen muß! Die sen¬ 
dende Einheit gibt nur Datenbits aus, wenn auch ein (Nutz-) Zeichen zur Übertragung vorliegt. 

Da in diesem Fall Pausen auftreten können, während der Sender und Empfänger aus der Syn¬ 
chronisation laufen könnten (und das auch tun), muß eine Synchronisationsinformation mit 
jedem übertragenen Zeichen mitgeführt werden. Deshalb wird jedem Zeichen ein Startbit 
(log. L) vorangestellt, damit der Empfänger informiert wird, daß nun wieder ein Zeichen über¬ 
tragen werden soll. Die Empfangseinheit beginnt mit dem Empfang des Startbits, den seriellen 
Bitstrom im Takt der eingestellten Übertragungsrate abzutasten. 

Am Ende eines Zeichens werden dann noch ein oder zwei Stopbits (log. H) angehängt, um den 
Empfänger über das Ende der Zeichenübertragung zu informieren. Wenn der Empfänger also 
dasStartbitunddievereinbarteZahlvonStopbitskorrekt erkannt hat,kann die Empfangseinheit 
davon ausgehen, daß auch das eigentliche Zeichen korrekt empfangen wurde. 

Der Taktgleichlauf zwischen Sender und Empfänger ist also nur für einen relativ kurzen Zeit¬ 
raum (nämlich für die Übertragungsdauer eines Zeichens + Start- und Stopbits) erforderlich 
und deshalb einigermaßen genau zu realisieren. Bei jedem neuen Zeichen hat der Empfänger 
mit dem Empfang des Startbits die Gelegenheit, sich neu zu synchronisieren. 


Serielle Datenübertragung mit dem ST 

Wie ja bereits zu Eingang des Kapitels erwähnt, besitzt der ST eine serielle Schnittstelle in 
Anlehnung an den RS-232C-Standard. Der ST ist dabei als Datenendeinrichtung (DEE) zu 
betrachten. Über eine TXD-Leitung (Transmitted Data) werden die Daten seriell ausgegeben; 
am RXD-Anschluß (Received Data) erwartet der ST die Empfangsdaten. Für den reibungs¬ 
losen Ablauf der Datenübertragung stellt die serielle Schnittstelle des ST fünf Handshake- 
Signale zur Verfügung. 
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Anschluß 

Bezeichnung 

ser. Port 

Bedeutung 

RTS 

Pin 4 

Request to send (Sendeteil einschalten) 

Der Anschluß geht auf “Ein”, wenn das Datenendgerät (der ST) 
etwas senden will. Mit “Aus”-Pegel wird signalisiert, wenn 
nicht gesendet werden soll. 

CTS 

Pin 5 

Clear to send (Sendebereitschaft) 

Rückmeldung der DÜE (Daten-Übertragungs-Einheit = Mo¬ 
dem), daß deren Sendeteil eingeschaltet ist und die zu senden¬ 
den Daten über die TXD-Leitung vom ST ausgegeben werden 
können (bei “Ein”-Signal dürfen Daten vom ST gesendet wer¬ 
den, sonst nicht!) 

DCD 

Pin 8 

Data carrier detect (Empfangssignalpegel liegt vor) 

Die DÜE meldet mit “Ein” an den ST, daß sie Signale mit aus¬ 
reichendem Pegel von der Gegenstation empfängt. 

DTR 

Pin 20 

Data terminal ready (DEE betriebsbereit) 

Der ST signalisiert der DÜE mit “Ein”-Pegel an diesem An¬ 
schluß Betriebsbereitschaft. 

RI 

Pin 22 

Ring indicator (Ankommender Ruf) 

Die DÜE meldet dem ST einen “Anruf’ von der Gegenstation. 
Das ist die “Telefonklingel”, mit der dem ST mitgeteilt wird, 
daß die Gegenseite einen Datenaustausch durchführen will. 
Das Signal wird eigentlich nur bei Modems benutzt, die in ei¬ 
nem als Mailbox arbeitenden Computer installiert sind. 


Der ST besitzt zwar unter seinen Peripheriebausteinen zwei sogenannte ACIAs (Asynchronous- 
Communications-Interface-Adaptor = Interface für asynchrone Datenübertragung), jedoch 
werden diese nicht für die Bedienung der herausgeführten seriellen Schnittstelle benutzt. Sie 
versorgen die MIDI-Schnittstelle und die “intelligente” Tastatur. 


Arbeitsteilung am RS232-Port 

Wie auch bei der parallelen Schnittstelle teilen sich bei der “Betreuung” der seriellen Schnitt¬ 
stelle des ST der PSG- (Programmable-Sound-Generator) und derMFP-Chip (Multi-Function- 
Peripheral) die Arbeit. 
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Die Parallel/Seriell-Wandlung der zu sendenden bzw. empfangenden Daten nimmt der MFP 
vor, welcher neben anderen interessanten Schnittstellen und Funktionseinheiten (Timer), 
auch einen USART (Universal Synchronous/ Asynchronous Receiver/Transmitter = Univer¬ 
selle Synchron/Asynchron Sende-/Empfangseinheit) besitzt. 

Die Datenübertragungsrate (Zahl der übertragenen Bits/Sek.) wird dabei durch die Taktfrequenz 
an den Anschlüssen TC (Transmitter Clock = Sendetakt, Pin 7) und RC (Receiver Clock = 
Empfangstakt, Pin 10) bestimmt, welche beim ST direkt miteinander verbunden sind. Gelie¬ 
fert wird der Takt vom Anschluß TDO (Timer-D-Output, Pin 16) des MFP. Sender und Emp¬ 
fänger arbeiten also immer auf der gleichen Taktffequenz (gleiche Datenübertragungsgeschwin- 
digkeit)! 



Abb. 5.1: So ist die serielle Schnittstelle des ST realisiert 
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Der Sender im USART des MFP besitzt ein Senderegister (Sendepuffer), in den das zu 
sendende Zeichen (maximal 8 Bit breit!) eingeschrieben wird. Von dort gelangt das Zeichen 
in ein Sendeschieberegister, das die Daten Bit für Bit im Takt der Übertragungsrate am SO- 
Ausgang des MFP (Pin 8) ausgibt. 

Die Übergabe des Zeichens vom Sendepuffer ins Sendeschieberegister geschieht automatisch 
dann, wenn das vorherige Zeichen aus dem Sendeschieberegister komplett “hinausgescho¬ 
ben” wurde. Der Status der Senderichtung kann aus dem Transmitter-Status-Register ausge¬ 
lesen werden. 

Genau umgekehrt ist der Ablauf im Empfangsteil des USART. Die seriellen Daten werden Bit 
für Bit über den SI-Anschluß des MFP (Pin 9) im Takt der vereinbarten Übertragungsrate in 
das Empfangsschieberegister “hineingeschoben”. Wenn die für ein Zeichen vereinbarte Zahl 
von Bits empfangen ist, wird der Inhalt des Empfangsschieberegisters in das Empfangsregister 
(Empfangspuffer) übertragen und kann von dort ausgelesen werden. Der Status der Empfangs - 
richtung wird über ein Receiver-Status-Register signalisiert. 

Damit die Datenübertragung interruptgesteuert durchgeführt werden kann (die CPU greift nur 
ein, wenn ein Zeichen komplett empfangen wurde und ausgelesen werden muß oder wenn ein 
neues Zeichen in den Sendepuffer gebracht werden muß oder wenn ein Fehler in der 
Übertragung aufgetreten ist), besitzt der USART des MFP für jede Datenrichtung zwei Inter¬ 
rupt-Kanäle. 

Ein RCV-Buffer-full-Interrupt (Priorität 12 bei MFP-Interrupts) signalisiert die Bereitstellung 
eines Zeichens im Empfangspuffer. Der Empfangspuffer sollte nun ausgelesen werden. Ge¬ 
schieht das nicht rechtzeitig, und wurde ein weiteres Zeichen bereits empfangen (steht im 
Empfangsschieberegister bereit), so wird ein RCV-Error-Interrupt (Priorität 11 bei MFP- 
Interrupts) ausgelöst. Weitere Bedingungen für RC V-Error-Interrupts werden bei der Bespre¬ 
chung der USART-Register erläutert. 

Ein XMIT-Buffer-empty-Interrupt (Priorität 10 bei MFP-Interrupts) wird ausgelöst, wenn das 
im Sendepuffer befindliche Zeichen in das Sendeschieberegister übertragen wurde und der 
Sendepuffer wieder gefüllt werden sollte. Wird das Senderegister nicht nachgeladen, bevor 
das Sendeschieberegister vollkommen geleert ist, so tritt ein XMIT-Error-üitermpt (Priorität 
9 bei MFP-Interrupts) auf. 


Die Register des MFP-US ART 


Für die Kontrolle des Sende- und Empfangsteils des MFP-US ART existieren fünf Register mit 
jeweils 8 Bit Breite. 
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Register Adresse Zugriff Bedeutung Label 

SCR $FF FA27 RAV Synchronous-Character-Register “SCR” 

Hier steht das Synchronzeichen, welches als Hilfszeichen für die Datenübertragung bei syn¬ 
chroner Betriebsart verwendet wird (zur Herstellung der Zeichensynchronisation mit der 
Gegenstelle). 

UCR $FF FA29 RAV USART-Control-Register “UCR” 

Durch Setzen bzw. Rücksetzen von einzelnen Bits werden verschiedene Betriebsmodi der 
seriellen Schnittstelle eingestellt. 

Even-/Odd-Parity Bit 


7 _ 6 5 4 3 2 1 0 


0 tte 

ULI 

UL G 

S1X 

sr g 

PE 

ESO 



Bei gesetztem Bit arbeitet der USART mit gerader Parität (Even Parity = Das zusätzlich in 
einem Daten wort enthaltene Paritätsbit wird so gesetzt, daß sich eine gerade Anzahl von Eins- 
Bits im Datenwort ergibt), sonst mit ungerader Parität (Odd Parity = Zahl der Eins-Bits eines 
Datenwortes wird durch das Paritätsbit auf ungerade ergänzt). 

Parity Enable Bit 


76543210 


Clk 

UL.t 

UL 0 

sr.i 

o 

PE 


0 


Bei gesetztem Bit findet die Datenübertragung mit Paritätsbit statt. Es wird also am Ende des 
zu übertragenden Zeichens ein zusätzliches Bit angehängt, welches entsprechend der gewähl¬ 
ten Art der Parität (Even/Odd) gesetzt wird. Siehe hierzu auch die Erläuterung des E/O-Bits. 

Format Control 


76543210 


IBH 


UL 0 

STJL 

STB 

PE 

E/8 

g 


Einstellung der Betriebsart und bei asynchroner Betriebsart die Zahl der Start- /Stop-Bits. 
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Register Adresse Zugriff Bedeutung Label 

UCR $FF FA29 R/W USART-Confrol-Register “UCR” 


ST1 

STO 

Start 

Bits 

Stop 

Bits 

Format 

0 

0 

— 

— 

Synchron 

0 

1 

1 

1 

Asynchron 

1 

0 

1 

1,5 

Asynchron 

1 

1 

1 

2 

Asynchron 


Der Betrieb mit 1,5 Stopbits ist nur möglich, wenn mit Vorteiler (Übertragungsrate ist 1/16 
des Taktes am TC/RC-Anschluß) gearbeitet wird (Clk-Bit gesetzt)! 

Word Length 


7654321B 


€A$i 

HLJ. 

rm 

S'ü 

ST 0 

PE 

E ZO 



Die Bitkombination legt fest, aus wie vielen Bits ein zu übertragendes Zeichen besteht. 


WI.l 

WLO 

Wortlänge 

0 

0 

8 Bits 

0 

1 

7 Bits 

1 

0 

6 Bits 

1 

1 

5 Bits 


Clock Mode 

76543210 


Clk 

Ui.i 

WL Ü 

ST1 



E/il 

Q 


Hiermit läßt sich einstellen, in welcher Beziehung Datenübertragungsrate und USART-Takt 
stehen. Bei gesetztemBitarbeitetderUSARTin der sogenannten“Vorteiler-Betriebsart”. Die 
an den TC/RC-Anschlüssen liegende Taktfrequenz wird in einem Vorteiler des US ART durch 
16 dividiert und bildet erst dann die Taktfrequenz für die serielle Datenübertragung. Bei 
gelöschtem Bit stimmen Taktfrequenz und Übertragungsrate überein. 
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Register Adresse Zugriff Bedeutung Label 

RSR $FF FA2B RAV Receiver-Status-Register “RSR” 

DerUSART meldet durch Setzen/Rücksetzen einzelner Bits den Status eines Zeichenempfangs. 
Außerdem läßt sich durch Setzen/Löschen einiger Bits das Verhalten des Empfängers steuern. 

Receiver Enable 


7 

6 

5 

4 

r 

3 

2 

1 

0 

FE 

FE 

fe 

r- e 

8 

H 

C3P 


m 


Empfänger Ein/Aus. Bei rückgesetztemBitistder Empfänger im USARTgesperrt. Außerdem 
werden alle Flags im RSR gelöscht. 

Synchronous Strip Enable 


0 


bf 


ÖE 


fe 


FE 


F/S 

H 

8 

C3F 


SS 


FE 


Nur bei Synchronbetrieb von Bedeutung. Bei gelöschtem Bit werden die empfangenen Syn¬ 
chronzeichen erst gar nicht in den Empfangspuffer übertragen. 

Es gelangen somit nur alle “Nutz-Zeichen” in den Empfangspuffer! 


Match/Character in Progress 


7 

G 

5 

4 

r 



1 

i 

0 

BF 

BF 

FE 

F E 

F/S 

0 

WM 

SS 

BE 


Synchronbetrieb: Match 

Ein gesetztes Bit signalisiert den Empfang eines Synchron-Zeichens. 
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Register Adresse Zugriff Bedeutung Label 


RSR $FF FA2B RAV Receiver-Status-Register “RSR” 

Asynchronbetrieb: Character in Progress 

Es wird aus dem gerade empfangenen Bitstrom ein Zeichen “zusammengebaut”. Mit Erken¬ 
nung des Startbits auf der Empfangsleitung wird das Bit gesetzt und mit Empfang des letzten 
Stopbits eines Zeichens wieder gelöscht. Also eine Art “BUSY”-Flag. 

Found/Search bzw. Break 


76543210 





r 

1ÄJ 

H 

r 


SF 

GE 


F E 

L 


r*£ 

B 

£3 P 

V>X> 

J 


Synchronbetrieb: Found/Search 

Durch Rücksetzen dieses Bits wird der Empfänger auf “Suchen” geschaltet. Der eintreffende 
Datenstrom wird auf Synchronzeichen untersucht. (Der Wortlängenzähler ist dabei ausge¬ 
schaltet, so daß die erste Bitfolge, die mit dem Zeichen im SCR (Synchronous-Character- 
Register) übereinstimmt, als Synchronzeichen erkannt wird). Wurde ein Synchronzeichen 
erkannt, so wird das Bit gesetzt, ein RCV-Error-Interrupt (siehe auch Teil II, Kapitel 4, 
“Interrupts durch den MFP-Baustein”) ausgelöst und der Wortlängenzähler eingeschaltet. 

Asynchronbetrieb: Break Detect 

Eine Pause in der Datenübertragung wird durch ein gesetztes Bit signalisiert. Es wird eine 
laufende Folge von “O-Bits” ohne Stopbit empfangen. Das Zeichen im Empfangspuffer ist ein 
“Break”-Zeichen (alles Nullen). Ein RCV-Error-Interrupt wird ausgelöst. Nach einem 
“Break” wird dieses Bit erst wieder gelöscht, wenn mindestens ein “1 -Bit” empfangen und das 
RSR gelesen wurde (Quittierung). 

Frame Error 


76543210 


m - 



— r 

f-VS 


- 1 



GE 

P'£ 

FE 

L 



8 




Ein gesetztes Bit signalisiert einen “Rahmenfehler”: dem im Asynchron-Betrieb empfange¬ 
nen (Nicht Null!)-Zeichen folgt kein Stop-Bit. Das Bit wird gelöscht, wenn ein korrekt “um¬ 
rahmtes” Zeichen empfangen wurde. (Hierfür wird kein RCV-Error-Interrupt ausgelöst!) 
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Register Adresse Zugriff Bedeutung Label 

RSR $FFFA2B RAV Receiver-Status-Register “RSR” 

Parity Error 


7 

G 

5 

4 

r 

3 

2 

1 

0 


OE 

PE 

rt: 

-“1 

f/S 

8 

H 

Ü 3 P 

SS 

4 

be 


Ein gesetztes Bit zeigt an, daß ein im Empfangspuffer befindliches Zeichen einen Parity- 
Febler aufweist. Dieser Fehler löst auch einen RCV-Error Interrupt aus. Das Bit wird gelöscht, 
sobald ein neues Zeichen ohne Parity-Fehler in den Empfangspuffer übertragen wird. 

Overrun Error 


7 

G 

5 

4 

3 

2 

1 

e 

BF 

OE 

PE 

Ft: 

— 

F/S 

1) 

N 

esp 

OO 

O s> 

4 

be 


Das Bit wird gesetzt, wenn ein gerade eingetroffenes Zeichen in den Empfangspuffer gebracht 
werden soll, dieser aber noch nicht ausgelesen wurde. Der Empfangspuffer wird jedoch nicht 
überschrieben. Weitere eintreffende Zeichen werden nicht beachtet, bis das Bit durch Lesen 
des RSR gelöscht wurde (Quittierung). Ein RCV-Error-Interrupt wird ausgelöst. 

Buffer Full 


7 

G 

5 

4 

r 



1 

T_ 

0 

□ 

OE 

PE 

Ft: 

i 

F/S 

8 



BE 


Das Bit wird gesetzt, sobald ein empfangenes Zeichen in den Empfangsbuffer übertragen 
wird. Gelöscht wird durch Auslesen des Empfangsbuffers (UDR = USART- Data-Register). 
Ein RCV-Buffer-Full-Interrupt wird ausgelöst. 

TSR $FF FA2D RAV Transmitter-Status-Register “TSR” 

Die Bits des TSR steuern den Sendeteil des USART und liefern Informationen über den Status 
des Sendeteils. 
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Register Adresse Zugriff Bedeutung Label 

TSR $FFFA2D R/W Transmitter-Status-Register “TSR” 


Transmitter Enable 

76543218 


UE 

Ui':. 

UJ 

emu 

u 

u 

L 

TE 


Bei gelöschtem Bit ist der Sender außer Betrieb. Als Folge davon wäre das “END-Bit” gesetzt 
und das “UE-Bit” gelöscht. Ein Setzen des Bits gibt den Sender frei. Bis zur Aussendung des 
ersten Zeichens ist der Ausgang des Senders auf High- bzw. Low-Pegel oder Hochohmig 
(abhängig von der Bitkombination der “High and Low-Bits”). 

High and Low 


76543210 


i>£ 

UE 

UJ 

EMU 

U 

n 

n 

JE 


Die Bitkombination dieser beiden Bits legt den Zustand des Senderausgangs (Anschluß SO 
des MFP) fest, wenn der Sendeteil gesperrt ist oder gerade erst freigegeben wurde. 


H 

L 

Senderausgang 

0 

0 

Hochohmig 

0 

1 

Low-Pegel 

1 

0 

High-Pegel 

1 

1 

Schleife 


Bei “Schleife” wird der Senderausgang intern mit dem Empfängereingang verbunden. Ebenso 
werden Sende- und Empfangstakt miteinander gekoppelt. Die Anschlüsse RC (Receiver 
Clock) und SI (Serial Input) werden in diesem Fall nicht mehr benutzt. 


Break 

76543210 


UE 

UE 


EUU 

ES 

it 

L 

JE 


Im Asynchron-Betrieb wird bei gesetztem Bit ein “Break” gesendet, sobald das Senderegister 
leer ist. 
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Register Adresse Zugriff Bedeutung Label 


TSR $FF FA2D RAV Transmitter-Status-Register “TSR” 

Während “Break” gesendet wird, erfolgt an jeder Zeichengrenze ein “XMIT- Error-Interrupt” 
mit gesetztem “END-Bit”. Sobald das “Break-Bit” gelöscht wird, erfolgt wieder normaler 
Sendebetrieb. 

End of Transmission 


76543210 


be 


& T 

»m 


h 

L 

YE 


Dieses Bit wird gesetzt, sobald der Sender gesperrt wird (TE-Bit). Ein XMIT-Error-Interrupt 
wird ausgelöst. 

Befindet sich zum Zeitpunkt der Sperre des Sendeteils gerade noch ein Zeichen im Sende¬ 
schieberegister, so geht das “END-Bit” erst auf “ 1 ”, wenn das Zeichen komplett ausgesendet 
wurde. 

Auto Tumaround 


76543210 


BE 

ÜE 

AT 

EMB 

B 

H 

ta 

re 


Bei gesetztem Bit wird der Empfänger automatisch erst dann freigegeben, wenn der Sender 
gesperrt und das letzte zu sendende Zeichen komplett ausgesendet wurde (bei Halbduplex- 
Betrieb ganz sinnvoll). 


Underrun Error 

7 6 5 4 3 2 1 0 


BE 

UE 

& Y 

EMB 

B 

n 

L 

re 


Bit gesetzt: Ein Zeichen ist komplett gesendet worden, bevor ein neues Zeichen in den Sende¬ 
puffer eingeschrieben wurde. Ein XMIT-Error-Interrupt wird ausgelöst. Dieses Bit wird mit 
dem Lesen des TSR oder durch Sperren des US ART-Sendeteils (Löschen des TE-Bits) wieder 
zurückgesetzt. 
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Register Adresse Zugriff Bedeutung Label 

TSR SFPFA2D R/W Transmitter-Status-Register “TSR” 

Buffer Empty 


76543216 


BE 

ü£ 


£.m> 

£ 

ü 

L 

n:-: 


Sobald das Zeichen aus dem Sendepuffer ins Senderegister gelangt, wird das Bit gesetzt. Ein 
XMTT-Buffer-empty-Interrupt wird ausgelöst. Mit Einschreiben eines neuen Zeichens in den 
Sendepuffer wird das Bit zurückgesetzt. 

UDR SFFFA2F RAV USART-Data-Register “UDR” 

Bei einem Schreibzugriff gelangt das eingeschriebene Byte in den Sendepuffer. EmLesezugriff 
liefert das Byte aus dem Empfangspuffer. Aus der Vielzahl der Steuermöglichkeiten und 
Rückmeldungen des USART läßt sich ersehen, wie flexibel die serielle Schnittstelle des ST 
bedient werden kann. 

Standardeinstellungen sind schon vorgesehen 

Die Übertragungsrate der seriellen Schnittstelle des MFP wird zwar durch Timer D bestimmt, 
jedoch sind im Betriebssystem schon Voreinstellungen für die gebräuchlichsten Datenübertra¬ 
gungsraten vorgesehen. Diese lassen sich, zusammen mit anderen Einstellungen, durch die 
XBIOS-Funktion #15 (“Rsconf’) abrufen. 

Leider hat die XBIOS-Funktion “Rsconf’ zwei Bugs (die von AT ARI aus “Kompatibilitätsgrün¬ 
den” auch in neueren TOS-Versionen nicht behoben wurden): 

- Die Übertragungsgeschwindigkeiten 50 und 75 Bit/s werden vom TOS falsch eingestellt 

(falsche Werte für das Timer-D-Data-Register)! Will man mit “Rsconf’ auf 50 Bit/s ein¬ 
stellen, läuft die serielle Schnittstelle in Wirklichkeit mit 80 Bit/s. Bei einer Einstellung 
auf 75 Bit/s ergibt sich in Wirklichkeit eine Geschwindigkeit von 120 Bit/s. 

Durch einen falschen Adreßdistanzwert in der “Rsconf’-Routine werden nicht - wie 
gefordert - die beim Aufruf gültigen Einstellungen der USART-Register SCR, UCR, 
RSR, und TSR in CPU-Register DO zufückgeliefert (SCR-Wert im höchstwertigen Byte, 
TSR-Wert im niedrigstwertigen Byte des Langworts), sondern die Werte für UCR, RSR, 
TSR und UDR! 
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Mit “Rsconf” lassen sich außerdem zwei verschiedene Handshaking-Methoden an wählen. Es 
ist sowohl Hardware-Handshake mittels RTS/CTS-Signalen möglich als auch Software- 
Handshake mit XON/XOFF-Betrieb. 

Im Betriebssystem des ST ist unter anderem auch für den Datenaustausch über die serielle 
Schnittstelle ein Pufferspeicher für die zu übertragenden Daten vorgesehen. 

Zu sendende Daten gelangen zunächst in einen Puffer und werden dann (interruptgesteuert) 
zeichenweise an die serielle Schnittstelle “weitergereicht”. Ähnlich ergeht es empfangenen 
Zeichen, welche per Interruptroutine aus dem USART-Data-Register (UDR) in einen Emp¬ 
fangspuffer transferiert werden. 


Protokolle sind manchmal wichtig 

Wird mit Hard- oder Software-Handshake gearbeitet, so werden die “Füllstände” der Puffer¬ 
speicher mit einer sogenannten “High- bzw. Low-water mark” verglichen. 

Werden die empfangenen Zeichen schneller in den Empfangspufferspeicher eingeschrieben, 
als sie durch z. B. ein Programm von dort ausgelesen werden können, wird der “Füllstand” 
irgendwann die “High-water mark” erreichen. 

Tritt dieser Fall ein, wird dem Sender der Gegenseite über EIN-Signal (+12V) am RTS- 
Anschluß des ST (bei Hardware-Handshake) bzw. durch Senden eines “Ctrl-S”-Zeichens = 
XOFF-Zeichen (bei Software-Handshake) signalisiert, die weitere Aussendung von Zeichen 
zu unterbrechen. 

Sinkt der “Füllstand” des Empfangspufferspeichers durch Auslesen von Zeichen dann wieder 
unter die “Low-water mark”, so wird die Gegenseite per AUS-Signal (-12V) an RTS (bei 
Hardware-Handshake) bzw. Senden eines XON-Zeichens=“Ctrl-Q” (bei Software-Handshake) 
darüber informiert, daß der ST wieder bereit ist, Daten aufzunehmen. 

Frühere TOS-Versionen (bis zum Blitter-TOS 1.02) erwarteten bei RTS/CTS-Handshake 
nach der Ausgabe jedes Zeichens ein Quittungssignal (kurzes “Ein”) über die CTS-Leitung. 
Außerdem wurde vom ST die RTS-Leitung nach dem Empfang eines jeden Zeichens für die 
Dauer der Verarbeitung auf “Aus” und erst anschließend wieder auf “Ein” gesetzt! 

In der TOS-Version 1.04 funktioniert der RTS/CTS-Handshake dann endlich wie gedacht, 
wenn er sich nur einschalten ließe! Die dazu nötige XBIOS-Routine #15 (Rsconf) hat einen 
Bug, der das Einschalten des RTS/CTS-Handshakes nicht erlaubt. Der Fehler läßt sich aber 
mit einem von ATARI gelieferten Autoordner-Programm (TOS14FTX.PRG) beheben. 
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Bei neueren TOS-Versionen (im MEGA STE und im TT!) hat ATARI diesen Bug nicht mit 
übernommen. Der RTS/CTS-Handshake läßt sich jetzt zwar mittels Rsconf-Aufruf setzen. 
Leider plaziert die Rsconf-Routine des TOS die Handshake-Parameter an eine Stelle in der 
IOREC-Struktur, die überhaupt nicht von den entsprechenden Interruptroutinen bei der Fest¬ 
stellung dergewünschtenHandshake-Betriebsartausgewertetwird(Rsconf trägt die Handshake- 
Art mittels Wordzugnff in die IOREC-Struktur ab Byte 32 ein, getestet wird die Handshake- 
Art aber in den Interrupt-Routinen mit By/ezugriffen auf Byte 33)! Auch hier kann man sich 
dann nur wieder mit entsprechenden Patch-Programmen helfen. 
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Kapitel 6: Die parallele Druckerschnittstelle 


Die ST-Computer besitzen eine Schnittstelle für den Anschluß eines Druckers mit Centronics- 
Interface. 

Die Centronics-Schnittstelle erlaubt gegenüber einer seriellen Schnittstelle relativ hohe 
Datenübertragungsraten, weil jeweils ein komplettes Byte über acht parallele Datenleitungen 
an den Drucker ausgegeben wird. Für die Darstellung der Informationszustände (Bit-High 
oder -Low) auf den Leitungen werden TTL-Pegel verwendet. 



Abb. 6.1: Timing-Diagramm der Centronics-Schnittstelle 


Eine STROBE-Leitung signalisiert dabei dem Drucker durch einen kurzen Low-Impuls, wann 
die auf dem 8-Bit-Bus liegenden Daten gültig sind. Die Daten werden bei der steigenden 
Flanke des STROBE-Impulses vom Drucker übernommen. 

Da der Computer in der Regel mit der Datenausgabe schneller ist, als der Drucker die Zeichen 
aufs Papier bringen kann, ist ein weiteres Handshaking-Signal zur störungsfreien Datenüber¬ 
tragung erforderlich. Über die BUSY-Leitung zeigt der Drucker dem Computer mit einem 
High-Pegel an, wenn er noch beschäftigt (busy) ist und noch keine neuen Daten aufnehmen 
kann. Üblicherweise stellen Drucker mit Centronics-Schnittstelle noch mindestens ein soge¬ 
nanntes ACKNLG-Signal (Acknowledge = Empfangsbestätigung) zur Verfügung, welches 
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durch Low-Impuls die korrekte Datenübemahme bestätigt. Dieses Signal wird jedoch von den 
ST-Computem nicht ausgewertet. 


Drucken mit Musik? 

Auch wenn für die parallele Schnittstelle der Soundchip benutzt wird, der ST macht während 
des Druckvorgangs keine Musik, um eventuell das nervtötende Geräusch eines sägenden 
Matrixdruckers zu übertönen. Vielmehr wird der PSG-Chip (Programmable-Sound-Genera- 
tor) des ST für die Datenausgabe auf den Drucker mitbenutzt. 

Wie der kurze Ausschnitt aus der ST-Schaltung zeigt, kommen die Interfaceleitungen für die 
Parallel-Schnittstelle von zwei verschiedenen Chips des ST-Computersystems. 



DB 25S 


+5Ü 


1K 


9. 


I 


18-55 — 
-c 


Data 
Data 
Data 
Data 
Data 
Data 
Data 
Data 0 
Strobe 
Busy 

Masse 


Pinlayout der Buchse 
_ tflufsichti _ 

13 12 11 10 9 S 7 6 5 4 3 5 1 

ooooooooooooo 

oooooooooooo 

25 24 23 22 21 20 19 18 17 IS 15 14 


Abb. 6.2: So ist die Centronics-Schnittstelle des ST auf gebaut 
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Der Port B des PSG-Chips 1 iefert die Signale für die acht Datenleitungen. An Port A, Anschluß 
IOA5, wird das STROBE-Signal generiert. Die Statusabfrage der BUS Y-Leitung erfolgt über 
den MFP-Baustein (Multi-Function Peripheral) an dessen Eingang 10. 

Für den Anschluß eines Druckers kann ein handelsübliches Druckerkabel mit DB 25S-Stecker 
auf der Seite zum Computer und 36pol. AMP-Stecker zum Drucker verwendet werden (wird 
auch für Anschluß von Druckern mit Centronics-An Schluß an PC-kompatible Computer be¬ 
nutzt). 

Die Zeichenausgabe an die Parallelschnittstelle wird natürlich voll vom Betriebssystem 
unterstützt (siehe auch BIOS-Funktionen #1, #2 und #3 (“Bconstat”, “Bconin”, “Bconout”)). 
Die Datentransferrate liegt bei ca. 4000 Bytes/Sek. (War das toll, wenn der Drucker da mit¬ 
käme), wobei die Ausgänge jeweils eine Standard-TTL-Last treiben können. 

Beim Anschluß von älteren Druckern mit Centronics-Interface sollte man darauf achten, daß 
die Druckereingänge eine nicht zu hohe Belastung für die PSG-Ausgänge darstellen. Ursache 
sind in der Regel zu niederohmige Pull-up-Widerstände im Drucker, die offene Eingänge auf 
High-Pegel ziehen sollen. Nachmessen kann man die Stromaufnahme der Eingänge, indem 
man bei eingeschaltetem Drucker einen Dateneingang des Centronics-Anschlusses über ein 
Milliampere-Meter oder Vielfachmeßgerät im mA-Bereich mit Masse verbindet. Der sich 
dann einstellende Strom ist auch jener Strom, den der PSG an seinen Ausgängen liefern können 
muß. Mit mehr als 3 mA sollte man den PSG nicht belasten. 


Keine Einbahnstraße! 

Nun sind aber die Ports des PSG sowohl als Aus- wie auch als Eingänge verwendbar. Mit der 
BIOS-Funktion #2 (“Bconin”) mit dem Parallelport als Eingabeeinheit (Char. Device #0) 
können über die parallele Schnittstelle Daten eingelesen werden! 

Man kann dabei den ST als “Drucker” betrachten, der mit Daten von z. B. einem anderen Com¬ 
puter beschickt wird. Über die STROBE-Leitung des Parallelports meldet der empfangende 
ST, ob er empfangsbereit (High-Pegel) oder beschäftigt (Low-Pegel) ist. Über den BUS Y-An¬ 
schluß erhält der empfangende ST die Signalisierung, daß die anliegenden Daten gültig sind 
(bei Low-Pegel). 


Vorsicht ist geboten! 

Man sollte bei der Benutzung des Parallelports als Eingang beachten, daß beim “Power-Up” 
des ST der Port B zunächst als Ausgang konfiguriert wird! Die Datenleitungen liefern so im 
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Ruhezustand ein Low. Eine an den ST sendende Einheit sollte also erst Daten (sprich 
Logikpegel) auf die Datenleitungen des Parallelports legen, wenn der empfangende ST den 
Port B auch auf “Eingang" geschaltet hat. Das ist am besten daran erkennbar, daß der 
STROBE-Anschluß des empfangenden ST auf High geht. 

Sonst könnte es geschehen, daß zwei verschiedene Pegel aufeinandertreffen (das Low vom 
empfangenden ST und ein eventuelles High vom sendenden Computer!). Diese Tatsache 
könnte der Soundchip übelnehmen und sich verabschieden! 

Die bidirektionale parallele Schnittstelle des ST wird von einigen Zubehör-Anbietern ausge¬ 
nutzt. So sind z. B. EPROM-Programmiereinrichtungen und Sound-Sampler erhältlich, die 
über die parallele Schnittstelle arbeiten. 


Ereigniszählung über den Druckerport 

Ein weiteres Detail, welches bei der Betrachtung des Schaltungsauszugs auffallt, ist die gleich¬ 
zeitige Verbindung der BUS Y-Leitung des Parallelports mit dem Eingang 10 des MFP und mit 
dem Anschluß TAI (Timer-A-Input)! Somit kann Timer A des MFP, welcher vom TOS nicht 
gebraucht wird, z. B. als Ereigniszähler oder zur Pulsweitenmessung benutzt werden. 

Außerdem ist der Eingang 10 des MFP, an welchem die BUS Y-Leitung der parallelen Schnitt¬ 
stelle aufläuft, ja ebenfalls als Interrupt-Eingang zu betreiben. Damit kann man einen Interrupt 
auslösen lassen, wennBUSY vom Drucker wiederauf Low gesetztwird. Damit wird ja signali¬ 
siert, daß ein weiteres Zeichen an den Drucker ausgegeben werden kann. Die zugehörige 
Interruptroutine kann nun ein weiteres Zeichen aus einem Pufferspeicher holen und ausgeben. 
In diesem Pufferspeicher werden sinnvollerweise alle Zeichen gesammelt, die von den Druck¬ 
ausgaberoutinen des Betriebssystems sonst direkt an den Drucker gesendet werden. 

Druckausgaben von Programmen füllen also schnell diesen Pufferspeicher und blockieren 
nicht lange die Arbeit mit dem ST, weil dieser warten muß, bis der Drucker alle Zeichen aufs 
Papier genadelt hat. Durch Ausnutzen des BUSY-Interrupts läßt sich also ein effektiver 
Druckerspooler programmieren (so z. B. im STMagazin 4/88, “Drucken ohne Zeitverlust”, 
beschrieben), weil wirklich die CPU nur dann mit Zeichenausgaben an den Drucker “belä¬ 
stigt” wird, wenn dieser bereit ist, ein neues Zeichen zu verarbeiten! 

Man sieht also, daß mit der parallelen Schnittstelle des ST noch einiges mehr anzufangen ist, 
als sie als simplen Druckeranschluß zu gebrauchen. Besonders dem Hardware-Bastler bieten 
sich hier noch einige interessante Möglichkeiten. 
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Kapitel 7: Die ACIAs im ST 


Im ST sind zwei Asynchrone-Communications-Interface-Adapter (ACIA) des Typs 6850 
eingesetzt. Sie helfen der CPU beim Datenaustausch mit der MIDI-Schnittstelle und der 
“intelligenten Tastatur”. Das “Innenleben” eines ACIAs soll die Abbildung 7.1 veranschau¬ 
lichen. 

Jeder ACIA stellt einen kompletten Kanal (Sende- und Empfangsteil) für die serielle Daten¬ 
übertragung nach der RS-232-Spezifikation zur Verfügung. 

Sender und Empfänger können dabei mit unterschiedlichen Taktfrequenzen gespeist werden 
(über die AnschlüsseTxCLK und RxCLK) und daher mit unterschiedlichen Datenübertragungs¬ 
geschwindigkeiten (in diesem Fall gleich der Baudrate, da Verwendung binärer Signale) 
arbeiten. 

Beim ST werden die beiden ACIAs jedoch, sowohl für die Sender- als auch die Empfängerseite, 
mit der gleichen Taktfrequenz (500 kHz) gespeist. 

Der ACIA für die MIDI-Schnittstelle arbeitet (lt. MIDI-Spezifikation) mit einer Datenübertra¬ 
gungsrate von 31250Bit/s, der ACIA für die “intelligente Tastatur” mit 7813)5 Bit/s. Wie aus 
dem Blockschaltbild hervorgeht, verfügt jeder ACIA über vier Register mit einer Breite von 
8 Bit. 

Die empfangenen seriellen Daten (über Anschluß RxDATA) werden zunächst in einem 
Empfangs-Schieberegister gesammelt. Ist ein Zeichen aus dem empfangenen seriellen 
Bitstrom “zusammengebaut”, wird es ins Empfangsregister übertragen und zur Signalisierung 
im Statusregister das Bit 0 (RDRF-Bit = “Receive data register fulT-Bit) gesetzt. Wenn der 
Empfänger-Interrupt zugelassen ist, wird auch gleichzeitig ein Interrupt ausgelöst. 

Die zu sendenden Informationen müssen dem ACIA über das Senderegister eingegeben 
werden. Es kann nur beschrieben werden. Ein zu sendendes Zeichen wird, nachdem es ins 
Senderegister eingeschrieben wurde, von dort ins Sende-Schieberegister übertragen und im 
Takt der Übertragungsggeschwindigkeit B it für Bit “ins Freie” geschoben (über den Anschluß 
TxDATA). 

Zur Signalisierung, daß das Senderegister geleert wurde, also ein neues Zeichen eingeschrie¬ 
ben werden kann, wird im Statusregister das Bit 1 (TDRE-Bit = “Transmitter data register 
empty”-Bit) gesetzt. Ist der “Sender-Interrupt” ffeigegeben, wird ein Interrupt ausgelöst, 
wenn das Senderegister wieder “nachgeladen” werden muß. 
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Abb. 7.1: Das Blockschaltbild des ACIA 6850 


ACIA-Steuerregister 

Nur Schreiben erlaubt! Bit für Bit lassen sich bestimmte Betriebsweisen des ACIA einstellen. 
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Bit 1 

BitO 

1 Funktion 

0 

0 

Baudrate ist gleich Taktfrequenz 

0 

1 

Baudrate ist 1/16 der Taktfrequenz (MIDI-Port) 

1 

0 

Baudrate ist 1/64 der Taktffequenz (Tastatur) 

1 

1 

Rücksetzung des ACIA (Master-Reset) 


Die Neuinitialisierung eines ACIAs muß softwaremäßig erfolgen. Das geschieht durch Setzen 
der beiden niederwertigen Bits im Steuerregister. 

Die Bits 2.4 des Steuerregisters bestimmen das Zeichenformat für die Datenübertragung. 


Bit-Nr.: 

4 1 

3 

2 

Funktion 


0 

0 

0 

7 Datenbits, gerade Parität, 2 Stop-Bits 


0 

0 

1 

7 Datenbits, ungerade Parität, 2 Stop-Bits 


0 

1 

0 

7 Datenbits, gerade Parität, 1 Stop-Bit 


0 

1 

1 1 

7 Datenbits, ungerade Parität, 1 Stop-Bit 


1 

o 

0 

8 Datenbits, keine Parität, 2 Stop-Bits 


1 

0 ! 

1 

8 Datenbits, keine Parität, 1 Stop-Bit 


] 

1 

0 

8 Datenbits, gerade Parität, 1 Stop-Bit 


1 

1 

1 ! 

8 Datenbits, ungerade Parität, 1 Stop-Bit 


Die Bits 5 und 6 im Steuerregister dienen zur Steuerung des Sendeteils. 


Bit 6 

Bit 5 

Funktion 

0 

o 

RTS auf Low, TxINT gesperrt 

0 

1 

RTS auf Low, TxINT freigegeben 

1 

0 

RTS auf High, TxINT gesperrt 

1 

1 

RTS auf Low, TxINT gesperrt, Break senden 


“Break senden“ bedeutet nichts anderes als die Sendeleitung bis auf weiteres auf Low-Pegel 
zu halten, also wird eine laufende Folge von O-Bits gesendet. 

Durch Setzen des Bit 7 des Steuerregisters wird der “Empfänger-Interrupt” (RxINT) einge¬ 
schaltet. So wird immer dann ein Interrupt ausgelöst, wenn das Empfangsregister voll ist und 
ein Zeichen ausgelesen werden soll. 

Weiterhin führt ein Low/High-Wechsel am DCD-Anschluß (Data Carrier Detect) oder ein 
Empfangsfehler (Receiver Overrun Error) zum Interrupt. 
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ACIA-Statusregister 

Dieses Register liefert Informationen über den Zustand einer Datenübertragung. Alle acht Bits 
signalisieren wieder verschiedene Betriebszustände oder Fehler. 

Bit 0 = “Receive Data Register Full” (RDRF-Bit) 

Wird gesetzt, sobald das Empfangsregister voll ist, also ein Zeichen ausgelesen werden muß. 
Dieses Bit wird gelöscht, wenn das empfangene Zeichen aus dem Empfangsregister ausge¬ 
lesen oder ein Master-Reset durchgeführt wird. 

Bit 1 = “Transmit Data Register Empty” (TDRE-Bit) 

Geht auf Log. 1, wenn der Sender wieder mit dem nächsten zu sendenden Zeichen “nachge¬ 
laden” werden muß. 

Bit 2 = “Data Carrier Detect” (DCD-Bit) 

Wird gesetzt, wenn der DCD- Anschluß auf High geht (Modem signalisiert: “Es wird kein Da- 
ten-Trägersignal empfangen”). Ist derRxINT freigegeben, wird auch ein Interrupt ausgelöst! 
Das Bit wird erst gelöscht, wenn das Status- und dann das Empfangsregister “bedient”, d. h. 
ausgelesen wurden. Bleibt danach der DCD-Anschluß weiterhin High, so wird zwar ein evtl. 
Interrupt gelöscht, das DCD-Bit bleibt aber weiter gesetzt, bis derDCD-Anschluß wieder auf 
Low geht. Im ST wird dieses Bit nicht verwendet, weil der DCD-Anschluß fest auf Low (Mas¬ 
se) liegt! 

Bit 3 = “Clear To Send” (CTS-Bit) 

Dieses Bit zeigt den Zustand des CTS-Anschlusses an. Ist der CTS-Anschluß High (Sender 
nicht bereit), bleibt auch das TDRE-Bit (Bit 1) unwirksam, da ja keine Daten gesendet werden 
können. Ein Master-Reset beeinflußt dieses Bit nicht! Im ST wird dieses Bit nicht verwendet, 
weil der CTS-Anschluß fest auf Low (Masse) liegt! 

Bit 4 = “Framing Error” (FE-Bit) 

Ein gesetztes Bit signalisiert einen Empfangsfehler. Es wurde ein “Nicht-Null”-Zeichen emp¬ 
fangen, dem aber “das Ende”, d. h. ein Stopbit fehlt. 

Bit 5 = “Receiver Overrun” (OVRN-Bit) 

Wird gesetzt, wenn ein empfangenes Zeichen im Empfangsregister “vergessen” worden ist. 
Das nächste bereits empfangene Zeichen hat das noch im Empfangsregister vorhandene Zei- 
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chen “überrannt”, d, h. überscbrieben, bevor es ausgelesen wurde. Ist der RxINT zugelassen, 
erfolgt auch eine Interrupt-Signalisierung. Ein gesetztes OVRN-Bit wird durch Lesen des 
Empfangsregisters oder einen Master-Reset gelöscht. 

Bit 6 = “Parity Error” (PE-Bit) 

Wenn Datenübertragung mit Paritätspriifung durchgeführt wird, signalisiert ein gesetztes PE- 
Bit, daß die Zahl der l -Bits des empfangenen Zeichens nicht mit der gewählten Parität (gerade 
oder ungerade Anzahl von 1-Bits) übereinstimmt. 

Bit 7 = “Interrupt Request” (IRQ-Bit) 

Geht bei einem Interrupt auf log. 1 (der TRQ-Anschluß wird bei einem Interrupt Lowl). 


Einbindung in die ST-Hardware 

Aufgrund der besonderen Registeranordnung (Zwei “Nur Lesen”- und zwei “Nur Schreiben”- 
Register) benötigt jeder ACIA nur zwei Adressen im I/O-Bereich eines Computersystems (so 
auch im ST). 

Im ST sind das die folgenden Adressen: 


Adresse 

Device 

Register 

Zugriff 

Labei 

$FF FCOO 

Tastatur 

Steuerregister 

Statusregister 

Write 

Read 

“keyctl” 

SFFFC02 

Tastatur 

Senderegister 

Empfangsregister 

Write 

Read 

“keybd” 

$FF FC04 

MIDI-Port 

Steuerregister 

Statusregister 

Write 

Read 

“midictl” 

SFFFC06 

MIDI-Port 

Senderegister 

Empfangsregister 

Write 

Read 

“midi” 


Die Register sind nur 8 Bit breit (also keine Wortzugriffe!). Auf welches Registerpaar zuge¬ 
griffen wird, hängt vom Zustand des RS-Anschlusses (Register Select) des ACIA-Chips ab. 
Über die R/W-Leitung wird dann das entsprechende Register angewählt. 


RS 

R/W 

ausgew. Register 

Zugriffsart 

0 

0 

Steuerregister 

Schreiben 

0 

1 1 

[ Statusregister 

Lesen 
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RS 

R/W 

ausgew. Register 

Zugriffsart 

1 

f- 

0 

Senderegister 

Schreiben 

1 

1 

Empfangsregister 

Lesen 


Soviel zum Innenleben des ACIA. Jetzt zum Einsatz der ACIA-Chips im ST. 


Die MIDI-Schnittstelle 

MIDI ist die Abkürzung für Musical-Instruments-Digital-Interface, was auf deutsch wohl mit 
“Digitale Schnittstelle für Musikinstrumente” übersetzt werden kann. 

Musikinstrumente und Effektgeräte, die ihre Klänge auf digitalem Wege erzeugen oder die 
Klangerzeugung digital steuern können (z. B. Synthesizer, elektronische Orgeln, Rhyth¬ 
musgeräte, Mischpulte), besitzen meist eine MIDI-Schnittstelle. Über diese Schnittstelle las¬ 
sen sich diese Geräte nun “fembedienen”. 

Um also mehrere Synthesizer und Effektgeräte simultan spielen zu können, braucht man nur 
ein Mastergerät, welches über nur einen Ausgang (MIDI-out) bis zu 16 Einheiten (Slaves) 
bedienen kann. 

Ist ein Computer mit seiner großen Speicherkapazität und Verarbeitungsgeschwindigkeit als 
Master angeschlossen, so kann dieser als Sequenzer eingesetzt werden, d. h., er versorgt pro¬ 
grammgesteuert die angeschlossenen Geräte mit Einstellungen oder kompletten Melodien. 
Die Instrumente werden sozusagen vom Computer gespielt. 

Weiterhin kann der Computer als digitale Bandmaschine arbeiten und z. B. über ein Keyboard 
gespielte Melodien aufzeichnen. Es wäre aber nun wenig sinnvoll, wenn per Tastendruck am 
Mastergerät ständig alle angeschlossenen Slaves (Synthesizer, Rhythmusmaschinen) reagie¬ 
ren würden. 

Man kann deshalb auch mit nur einem Ausgang am Master, über eine durchgeschleifte Ver¬ 
bindung (bei den Slaves in MIDI-in rein und bei MIDI-Thru wieder raus zum nächsten Slave) 
an mehrere angeschlossene Einheiten verschiedene Informationen senden. Diese Informatio¬ 
nen müssen nur entsprechend “adressiert” werden. Folgende Betriebsarten sind möglich: 

Der OMNI-Modus ist die einfachste Betriebsart. Nach einem RESET befinden sich alle Geräte 
in diesem Modus. Alle Instrumente, die an einem Bus hängen, spielen parallel und mehrstimmig 
(polyphon). Es existiert also eigentlich nur ein Kanal, und das gezielte Ansprechen eines ein¬ 
zelnen Geräts ist nicht möglich. 
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Per POLY-Modus lassen sich verschiedene Geräte separat ansteuem. Jeder Slave bekommt 
eine Kanalnummer zugeordnet, die für ihn gültig ist. Das Gerät hat nur auf Kommandos zu 
reagieren, die auf “seinem” Kanal empfangen werden, also mit seiner Kanalnummer adres¬ 
siert sind. So können dann mit beliebig vielen Instrumenten maximal 16 verschiedene Melo¬ 
dien (auf jedem Kanal eine andere) gespielt werden. 

Der MONO-Modus ist die komplexeste Betriebsart. Man kann damit einzelnen Stimmen eines 
Synthesizers getrennte Kanäle zuordnen und so unabhängig voneinander beeinflussen. Jede 
Stimme kann nun wie ein einzelner einstimmiger (monophoner) Synthesizer angesprochen 
werden. Verfügt ein löstimmiger Synthesizer über die Mono-Betriebsart, kann also auf die¬ 
sem mit nur einem Sequenzer ein Orchester mit bis zu 16 monophonen Instrumenten gespielt 
werden! 

Man unterscheidet bei der MIDI-Datenübertragung die beiden großen Gruppen Statusbytes 
und Datenbytes. Die Datenbytes enthalten die Daten zu einem Kommando und folgen einem 
Statusbyte. Das Statusbyte “sagt”, was gemacht werden soll, während die Datenbytes die nöti¬ 
gen Informationen beinhalten, mit denen die angesprochene Einheit eingestellt werden soll 
(z. B. Schalter- bzw. Reglerstellung). Einem Statusbyte folgen normalerweise zwei Datenbytes. 

- MIDI-Statusbytes unterscheiden sich von den Datenbytes durch ein gesetztes achtes 
Datenbit. Sie lassen sich unterteilen in: 

- Kanalkommandos 

Hierzu gehören die sogenannten Voice-Commands, welche zur Steuerung und 
Programmierung von einzelnen Instrumenten-Stimmen dienen. Mit ihnen werden 
Töne ein- oder ausgeschaltet, Tonhöhen eingestellt oder Informationen über Tasten- 
Anschlagsdynamik (“attack velocity” bzw. Tasten-Loslaßdynamik (“release velo- 
city”) und über den Tastendruck (“after touch”) gegeben. Außerdem können bis zu 
32 Regler und 32 Schalter zur Klangeinstellung betätigt werden. Die Schalter-/ Reg- 
lemummer und die Schalter-/ Reglerstellung sind in den Datenbytes enthalten. 

Die zweite Gruppe der Kanalkommandos sind die Modus-Kommandos. Mit ihnen 
wird einem Instrument mitgeteilt, in welcher Betriebsart gearbeitet werden soll 
(Omni-, Poly- oder Mono-Mode). Weiterhin läßt sich damit z. B. die Tastatur eines 
Synthesizers abschalten, so daß er nur über MIDI gespielt werden kann. 

- Systemkommandos 

Diese gelten nicht für einen bestimmten Kanal. Man unterscheidet bei den Systemkom¬ 
mandos drei Gruppen; 
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1 WM 

Daten- 
Byte 1 

Daten- 
Byte 2 

Bedeutung 

8B..8F 

9 

BB..7F 

HQTE OFF (nit Kanalnr.) gefolgt 
von Hotennr. und UELOCITY (00=Note Off, 
Bi=pianissino, 7F=fortissimo) 

50.,9F 

1 1 

0B..7F 

NOTE OH (nit Kanalnr.) gefolgt 
von Hotennr. und UEL0CITY 

BQ..BF 

BB..7F 

00..7F 

POLYPRESSURE (nit Kanalnr.) gefolgt 
von Hotennr. und PRESSURE URLUE 

BB..BF 

00..1F 

00..7F 

C0HTR0L CHRHGE (nit Kanalnr.) gefolgt 
von COHTROLLER-Hr. (1..32, CTL.-Hr.l=00) 
und COHTROLLER-UflLüE-MSB ü.,128) 

11 II 

20,.3F 

00..7F 

CONTROL CHRHGE (nit Kanalnr.) gefolgt 
von CONTROLLER-Nr. (1..32, CTL.-Nr.l=20) 
und CONTROLLER-VRLUE-LSB (1..128) 

II II 

40..5F 

00..7F 

SWITCH CHRHGE (nit Kanalnr.) gefolgt 
von SWITCH-Nr. (1..32, SW.-Hr.1=00) 
und SWITCH-POSITIOH (00=Off, 7F=0n) 

CB..CF 

60..7F 


PROGRRM CHRHGE (nit Kanalnr.) gefolgt 
von PROGRRM-Nr. 


00..7F 


CHRHHEL PRESSURE (nit Kanalnr.) gefolgt 
von PRESSURE-URLUE 

EB..EF 

00..7F 

00..7F 

PITCH MHEEL CHRHGE (nit Kanalnr.) gefolgt 
von URLUE-LSB und URLUE-HSB 


Abb. 7 . 2 : Voice Commands 


Common Commands haben Einfluß auf alle angeschlossenen Geräte und werden 
benutzt, um einen bestimmten Song oder eine Sequenz oder eine bestimmte Stim¬ 
mung auszuwählen oder um ein System-Reset auszufiihren. 

RealTime Commands dienen zur Synchronisation der Instrumente. Mit ihnen werden 
Rhythmusmaschinen gestartet, gestopptodergetaktet. IhnenfolgenkeineDatenbytes. 
Sie können auch zwischen Datenbytes anderer Kommandos gesendet werden. 

Exclusive Commands sind herstellerspezifische Informationen für Sonderfunktionen, 
die nicht von jedem Gerät beherrscht werden. Sie können beliebig viele Datenbytes 
hinter sich herziehen. 
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Wi 

Daten- 
Byte 1 

Daten- 
Byte 2 

Bedeutung 

Be..BF 

70 

00 / 7F 

LOCAL KEYBOARD COHTROL (nit Kanalnr.) 
gefolgt von ‘7A 1 und SHITCH-VALUE 
(OB = LOC. KBD. off, 7F = LOC. KBD. on) 

II 1! 

78 

0B 

ALL KOTES OFF (nit Kanalnr.) 

II II 

7C 

— 

DMHI MODE OFF (nit Kanalnr.) 

II II 

7D 

00 

OMNI MODE OH (nit Kanalnr.) 

II li 

7E 


MONO MODE OH / POLY MODE OFF (nit Kanal¬ 
nr.) gefolgt von '7E' und Anzahl der 
nonophon gespielten VOICES (OB = alle 
DQICES des Instrunents)) 

II II 

7F 


POLY MODE OH t MOH0 MODE OFF 
(nit Kanalnummer) 


Abh. 7.3: Mode Commands 


Die technische Realisierung der MIDI-Schnittstelle 

Die MIDI-Schnittstelle arbeitet nach dem Stromschleifen-Prinzip (gearbeitet wird mit einer 
Standardstromstärke von ca, 5 mA), d. h,, “Strom” und “kein Strom” sind die Aussagen für 
eine logische 0 oder I. Dieses Prinzip ist bei größeren Leitimgslängen wesentlich unempfind¬ 
licher gegenüber Störungen als die Datenübertragung mit Spannungspegeln. 

Die Datenübertragungsrate liegt nach der MEDI-Spezifikation bei 31,25 kBit/s. Ein Zeichen 
ist 8 Bit breit, umrahmt von einem Start- und Stopbit. Ein Bit ist also 32 pSek. lang; die Übertra¬ 
gung eines Zeichens dauert somit 320 pSek. Optokoppler an den Eingängen (MIDI-in) sorgen 
füreinePotentialtrennungderangeschlossenen Einheiten und verhindern so Masseverschleifun- 
gen und Brummstörungen. 

Der serielle MIDI-Bus hat für jede Datenrichtung eine eigene Leitung. An MIDI-in werden 
Daten empfangen, über MIDI-out ausgesendet. Beim ST werden die empfangenen Daten von 
MIDI-in nach MIDI-out durchgeschleift. So wird die Funktion MIDI-Thru realisiert. 

Den Empfang von seriellen Daten melden sowohl der MIDI- als auch der Tastatur-ACLA über 
einLow-Signal auf der IRQ-Leitung. Beide ACIA-IRQ-Anschlüsse sind miteinander verbun¬ 
den (Open-Collector-Ausgänge) und laufen am Eingang 14 des MFP auf. 
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Status- 

Byte Bedeutung 


Connon Infornations 


nicht definiert ! 

SONG-POSITION (die beiden folgenden Datenbytes enthal¬ 
ten LSB und MSB der SONG POSITION. (I Count = 6 MIDI- 
Clocks)) 


SONG SELECT (das folgende Datenbyte enthält die SONG- 
NUMBER) 


F4..F5 nicht definiert ! 


TUNE REOUEST 



SYSTEM RESET 


Real Tine Infornations! 



TIMING CLOCK (24 Clockinpulse / Viertel-Note) 


nicht definiert ! 


START (setzt SONG POSITION-Pointer zurück!) 




nicht definiert ! 


ACTIVE SENSING (wird in Pausen alle 300 ns gesendet, un 
Enpfänger bereit zu halten!) 


Systen Exclusive Infornations 



SYSTEM EXCLUSIVE (das folgende Datenbyte enthält die 
Herstelleridentifikation; beliebig viele Datenbytes 
können folgen!) 


END OF SYSTEM EXCLUSIVE (zeigt Ende der SYSTEM EXCLU- 
SIV-Daten an) 


Abb. 7.4: System Commands 
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Welcher ACIA (Tastatur oder MIDI) “interrupted” hat, muß dann in der Interruptroutine für 
den Port 14 des MFP, durch Abfrage der beiden ACIA-Statusregister ermittelt werden. 

Auch am MIDI-in Eingang des ST findet man natürlich den MIDI-typischen Optokoppler zur 
Potentialtrennung (siehe Abbildung 7.5). Das empfangene MIDI-Signal wird gleich wieder 
an die MIDI-out Buchse (Pin 3 + 1) durchgeschleift (MIDI-Thru-Funktion). 


Für die Wandlung von log. Pegeln des ACIA-Ausgangs TxDATA auf die Stromsteuerung der 
MIDI-Schnittstelle sorgen die Inverter, gebildet mit TTL-Chips des Typs “LS04” und “LS05”. 



Abb. 7.5: Die MIDI-Schnittstelle des ST 
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Die “LS05”-Inverter besitzen dabei Open-Collector-Ausgangsstufen und schalten damit nur 
den Strom im Ausgangskreis ein bzw. aus. Da es bei MIDI keinen hardwaregesteuerten Hand¬ 
shake gibt, sind die entsprechenden Anschlüsse des ACIA (RTS, CTS, DCD) unwirksam ge¬ 
schaltet. 

Softwaremäßig wird die Programmierung der MIDI-Schnittstelle vom TOS durch die XBIOS - 
Funktionen #12 (“Midiws”) und #14 (“Iorec”) unterstützt. “Iorec” arbeitet jedoch, im Gegen¬ 
satz zur Datenübertragung über die RS232-Schnittstelle, bei MIDI-Betrieb nur mit einem 
Empfangspuffer. 


Die Tastatur 

Die üppig ausgelegte Tastatur des ST (95 Tasten) hilft dem Anwender dabei, sich dem 
Betriebssystem “bemerkbar” zu machen. Ein Tastendruck muß dabei in ein entsprechendes 
Zeichen umgeformt und dem TOS übergeben werden. Außerdem ist laufend zu überwachen, 
was der Anwender mit der Maus und/oder evtl, einem angeschlossenen Joystick anstellt. Um 
die CPU dabei möglichst wenig mit dieser eintönigen Tätigkeit (die größte Zeit vergeht dabei 
mitdem Warten aufeinen Tastendruck oder eine Mausbewegung) zu belasten, wurde für diese 
Aufgabe ein eigener Mikrocontroller herangezogen. 

Damit dieser sich während des Wartens auf irgendwelche Reaktionen nicht zu sehr langweilt, 
darf er sich auch noch gleichzeitig als Uhr betätigen. Mittels einer zusätzlichen Batterie oder 
eines Akkus kann man den IKBD-Chip (Intelligent-KeyBoarD-Chip) auch dann mit Energie 
versorgen, wenn der ST ausgeschaltet ist. So erhält man eine Uhr, die immer richtig geht (siehe 
auch Bauanleitung in 68000er 3/87)! 


Ein eigener Computer für die Tastatur 

Für diese Aufgabe wurde ein Single-Chip-Mikrocomputer der 6800-Familie eingesetzt, der 
“6301V1”. Er enthält in einem normalen 40pol, DIL-Gehäuse eine 8-Bit-CMOS CPU, 
4KByte ROM, 128 Bytes RAM, einen 16-Bit-Timer, eine serielle Schnittstelle und vier I/O- 
Ports mit insgesamt 29 Portleitungen! Abbildung 7.6 gibt einen Einblick in das Innenleben des 
IKBD-Chips. 


Die Denkzentrale 

Die CPU des IKBD-Chips enthält zwei 8-Bit-Akkumulatoren A und B, die auch zusammen 
als ein 16-Bit-Akku D arbeiten können. Weiterhin existiert noch ein 16-Bit-Index-Register 




Mehrere Betriebsarten zur Auswahl 

Im Blockschaltbild findet sich, neben bekannten Funktionsblöcken, wie man sie von anderen 
Mikrocontrollem kennt, auch ein sogenannter Mode-Control-Block. Dieser Mode-Control- 
Block wird beieinemResetbenutzt, um festzustellen,in welcherBetriebsartderMikrocontroller 
arbeiten soll. 
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Adr. $0003 

Daten-Bits von Port 2 

Mode-Bits (werden nach einem Reset 
von P20..P22 eingelesen) 

Im ST arbeitet der 6301 im Single-Chip-Modus (Mode 7). Alle Ports werden dabei für I/O- 
Zwecke benutzt. Der Expanded-Multiplex-Mode (Mode 0,2,4 oder 6) wird benutzt, um den 
Adreßraumdes 6301 mit externen ROMs/RAMs auf bis zu 64 KBytes zu erweitern. Port 3 wird 
dabei zu einem gemultiplexten Daten-/Adreßbus umfunktioniert. 

Weitere acht Adreßleitungen können an Port 4 zur Verfügung gestellt werden. 

Im Expanded-Non-Multiplexed-Mode (Mode 1 und 5) kann der 6301 ebenfalls bis zu 64 
KByte adressieren. Port 3 wird dann für den Datenbus, Ports 1 und 4 für den Adreßbus benutzt. 
Außerdem kann der 6301 in diesem Modus Peripherie-Bausteine der 6800-Familie direkt 
(ohne Adressen-Zwischenspeicherung) ansprechen. Welcher Modus gewünscht ist, erfahrt 
der 6301 bei einem RESET über die Portleitungen P20..P22 von “außen”. 

Softwaremäßig läßt sich der Modus dann nicht mehr ändern. 

Wie man aus dem Schaltbild der ST-Tastatur (siehe Abbildung 7.7) ersehen kann, liegen die 
drei Anschlüsse P20...P22 beim ST über Pull-up-Widerstände auf High (drei “Hl” ergibt 
Mode 7!). Man kann beim ST jedoch einen anderen Modus einstellen, indem man bei einem 
RESET des ST eine oder beide Maustasten gedrückt hält. Damit “zieht” man den Eingang P21, 
P22 oder beide auf Low-Pegel und setzt im Mode-Register einen Modus von 1, 3 oder 5. 

Das führt aber nur dazu, daß man mit der Tastatur und der Maus nicht mehr arbeiten kann, da 
der Tastaturprozessor ja von Atari als Single-Chip-Anwendung (Modus 7) konzipiert ist. 

Weil Modus 5 und 7 nahezu identisch sind, darf man jedoch beim Einschalten seines STs ruhig 
die linke Maustaste gedrückt halten! 

Das Gedächtnis des Tastaturchips 

Die Funktionsblöcke RAM und ROM brauchen eigentlich keine weitere Erläuterung. Die 128 
Bytes RAM werden bei der ST-Tastatur für die Zwischenspeicherung von Tastencodes und 
Mausaktionen sowie für einige Pointer, den Stack, Uhrzeitdaten usw. benutzt. Im ROM ist das 
“Betriebssystem” des IKBD-Chips untergebracht. 
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$0000 
» 

$001F 

’ nicht benutzbar 


interne 

Register 


$0080 


$00FF 


nicht benutzbar 


$F000 


$FFEE 

$FFF0 

$FFF2 

$FFF4 

$FFF6 

$FFF8 

$FFFA 

$FFFC 

$FFFE 


internes 
ROM 
(4 KBytes) 

TRAP-Int. Vektor 
SCI-Inter. Vektor 
TOF-Inter. Vektor 
OCF-Inter. Vektor 
ICF-Inter. Vektor 
IRQ1- Int. Vektor 
Software Inter. 
NMI-Inter. Vektor 
RESET-Int. Vektor 


internes 

RAM 

(128 Bytes) 


Memory Map des 6301 im Mode 7 (Single-Chip-Modus) 


Wie spät ist es? 

Der Timer-Block des Tastaturprozessors enthält einem freilaufenden 16-Bit-Zähler. Dieser 
Zähler wird mit 1/4 der Systemtaktfrequenz (das entspricht dem Takt des E-Anschlusses) 
hochgezählt. Im ST arbeitet der 6301 mit 4 MHz Systemtakt, so daß der 16-Bit-Zähler des Ti¬ 
mers mit 1 MHz gefahren wird. Der Zähler kann jederzeit ausgelesen werden. Ein Beschrei¬ 
ben mit einem neuen Startwert ist ebenfalls möglich, dabei sind jedoch Doppel-Byte-Schreib- 
zugriffe zu verwenden (16-Bit-Register!). 
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16 Bit-Free-Running-Counter (FRC) 

Adr. $0009 Adr. $000A 

XXXXXXXX XXXXXXXX 

High-Byte Low-Byte 

Es können IRQ2-Interrupts durch den Timer ausgelöst werden, sobald ein bestimmter Zähler¬ 
stand erreicht ist oder sobald dieser von $FFFF -> $0000 zählt (Timer Overflow). Auch durch 
ein Triggerereignis von außen kann der augenblickliche Zählerstand “eingefangen” und so der 
Timer für Zeitmessungen benutzt werden. 


16 Bit-Output-Compare-Register (OCR) 

Adr. $000B Adr. $OOOC 

XXXXXXXX XXXXXXXX 

High-Byte Low-Byte 

Erreicht der FRC den im OCR eingestellten Wert, kann überP21 ein Ausgangsimpuls abgege¬ 
ben und ein Interrupt ausgelöst werden. 


16 Bit-Input-Capture-Register (ICR) 

Adr. $000D Adr. $000E 

XXXXXXXX XXXXXXXX 

High-Byte Low-Byte 

Durch Flankenwechsel an P20 kann der augenblickliche FRC-Zählerstand im ICR “einge¬ 
fangen” werden. Gleichzeitig kann ein Interrupt ausgelöst werden. 


8 Bit-Timer-Control/Status-Register (TCSR) 


L 


ICF OCF TOF EICI EOCI 


BTÖlTffiDG OLVL | 


Adr. $0008 


ICF (Input-Capture-Flag). Gesetzt, sobald ein entsprechend dem IEDG-Bit eingestellter 
Flankenwechsel stattgefunden hat. 

OCF (Output-Capture-Flag). High, sobald Wert im OCR mit FRC übereinstimmt. 

TOF (Timer-Overflow-Flag). Gesetzt bei $FFFF -> $0000-Übergang des Free-Running- 
Counters (FRC). 
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EICI (Enable-Input-Capture-Interrupt). Bei gesetztem Bit kann eine Interrupt-Anforde¬ 
rung durch entsprechenden Flankenwechsel an P20 ausgelöst werden. 

EOCl (Enable-Output-Capture-Interrupt). Freigabe der Interrupt-Anforderung bei Über¬ 
einstimmung von OCR und FCR. 

ETOI (Enable-Timer-Overflow-Interrupt). Bei gesetztem Bit wird ein Interrupt bei Timer 
Overflow ($FFFF -> $0000-Übergang) ausgelöst. 

1EDG (Input-Edge). Bei gesetztemBiterfolgt“Input-Capture”(“Einfangendes augenblick¬ 
lichen FRC-Wertes”) bei ansteigender Flanke anP20. “Input-Capture” auffallender 
Flanke erfolgt bei gelöschtem Bit, Der P20-Anschluß muß natürlich als Eingang pro¬ 
grammiert sein. 

OLVL (Output-Level). Tritt “Output-Capture” ein (Übereinstimmung zwischen OCR und 
FRC), wird der OLVL-Bit-Wert am Port P21 präsentiert (natürlich nur, wenn der 
P21-Port als Ausgang programmiert ist). 


Daten im Gänsemarsch 

Der SCI-Block enthält das sogenannte Serial-Communications-Element, die serielle 
Schnittstelle des 6301. Es handelt sich hierbei um eine Vollduplex-Schnittstelle, mit der dem 
ST die Informationen über betätigte Tasten, Mausbewegungen, Mausclicks und Uhrzeit über¬ 
mittelt werden. Das Datenformat beträgt dabei acht Datenbits mit einem vorangestellten Start¬ 
bit und zur Signalisierung des Zeichenendes ein Stopbit. 

Es gibt auch hier, wie schon bei den ACIAs, ein Sende- und ein Empfangsregister. In einem 
Rate/Mode Control-Register wird die Datenübertragungsrate (im ST wird mit Systemtakt/512 
= E/128 = 1 MHz/128 = 7812,5 Bit/s gearbeitet) eingestellt und ausgewählt, ob der erforder¬ 
liche Takt von einer externen Taktquelle kommt oder intern erzeugt wird. 

Ein Tx/Rx-Control-/Statusregister gibt Auskunft über evtl. Fehler bei der Datenübertragung 
und ob Daten empfangen wurden und zur Weiterverarbeitung ausgelesen werden sollen oder 
ob neue Daten ins Senderegister geschrieben werden können. 

Senderegister Empfangsregister 

Adr. $0013 Adr. $0012 


xxxxxxxx 


xxxxxxxx 
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Transmit/Receive-Control and Status-Register (TRCSR) 


RDRF 

ORFE 

TDRE | RIE 

RE 

TIE 

TE 


Adr. $0011 


RDRF (Receive-Data-Register-Full). Gesetzt, sobald ein empfangenes Zeichen aus dem 
Empfangsregister abgeholt werden kann. 

ORFE (Over-Run-Framing-Error). Gesetzt, wenn ein Framing-Error oder ein Überlauf 
(empfangenes Zeichen wurde nicht rechtzeitig aus Empfangsregister ausgelesen) 
aufgetreten ist. 

TDRE (Transmit-Data-Register-Empty). Wird gesetzt, sobald das Senderegister “nachgela¬ 
den” werden kann. 


RJE (Receive-Interrupt-Enable). Durch Setzen dieses Bits wird der Empfänger-Interrupt 

freigegeben, der bei RDRE=1 od. ORFE=l ausgelöst wird. 

RE (Receiver-Enable). Mit Setzen des Bits wird Port P23 zum Empfangsanschluß des 
SCI. Der Empfangsteil ist eingeschaltet. (Im ST realisiert.) 

TIE (Transmit-Interrupt-Enable). Bei gesetztem Bit ist der Sender-Interrupt freigegeben, 

der bei TDRE=1 ausgelöst wird. 

TE (Transmit-Enable). Mit Setzen dieses Bits wird Port P24 als Senderausgang geschal¬ 

tet. Der Sendeteil des SCI ist eingeschaltet. (Im ST realisiert.) 

WU (Wake-Up). Wird dieses Bit gesetzt, so werden Empfangsdaten so lange ignoriert, 
bis zehn 1 -Bits empfangen werden. Mit einer Folge von zehn 1-Bits wird also der 
Empfänger erst “aufgeweckt”. 


Rate- and Mode-Control-Register (RMCR) 



- i -! cci 

ccoj 

[ssT 

sso| 



i 

0 

I 

0- 



0 

1 - 



1 

0- 



1 

1 - 


Adr. $0010 
Baudrate = E/16 

• Baudrate = E/128 (im ST verwendet) 
Baudrate = E/1024 

• Baudrate = E/4096 
(E=l/4 des Systemtakts) 


0 0 keine Funktion 

0 1 interner Takt (im ST verwendet) 

1 0 interner Takt an P22 herausgefuhrt 

1 1 externer Takt von P22 
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Die Verbindung zur Außenwelt 

Die vier Ports mit ihren insgesamt 29 Portleitungen werden bei der “intelligenten Tastatur” 
des ST überwiegend benutzt, um eine Tastaturmatrix zu bilden und dann “Kurzschlüsse” (Ta¬ 
stenbetätigungen) in dieser Matrix zu entsprechenden Tastaturcodes umzuwandeln. Maus¬ 
bewegungen und Joystick-Betätigungen werden ebenfalls in dieser Matrixabfrage berück¬ 
sichtigt. Lediglich die Fire Buttons/Maustasten sind nicht in die Matrix eingebunden und wer¬ 
den direkt an zwei Ports des 6301 abgefragt. 

Beim 6301 kann im Single-Chip-Mode jeder Portanschluß individuell als Ein- oder Ausgang 
programmiert werden. Dazu existiert für jeden Port ein Datenrichtungsregister (Bit auf High 
= zugehöriger Portanschluß ist als Ausgang eingestellt). 


Port 

# 

Adresse 

Bitbelegung 

Bedeutung 

1 

$0002 

P17 P16 P15 P14 P13 P12 Pli P10 

Port-Datenregister 

1 

$0000 

P17 P16 P15 P14 P13 P12 PU P10 

Datenrichtung 

2 

$0003 

PC2 PCI PCO P24 P23 P22 P21 P20 

Port-Datenregister 

2 

$0001 

P24 P23 P22 P21 P20 

Datenrichtung 

3 

$0006 

P37 P36 P35 P34 P33 P32 P31 P30 

Port-Datenregister 

3 

$0004 

P37 P36 P35 P34 P33 P32 P31 P30 

Datenrichtung 

4 

$0007 

P47 P46 P45 P44 P43 P42 P41 P40 

Port-Datenregister 

4 

$0005 

P47 P46 P45 P44 P43 P42 P41 P40 

Datenrichtung 


Eine Sonderstellung nimmt der Port 2 im ST ein. Port P23 ist als Empfangsport für serielle 
Daten geschaltet. Die serielle Ausgabe von Daten erfolgt über Port P24. Im ST sind diese bei¬ 
den Ports mit den TxDATA- und RxDATA-Anschlüssen des Tastatur-ACIAs verbunden. 
Immer wenn ein Zeichen von der Tastatur vorliegt, welches dem TOS bekanntgemacht wer¬ 
den sollte, wird dieses zum Tastatur-ACIA im ST gesendet. Dieser löst einen Interrupt über 
Port 4 des MFP aus und informiert so das Betriebssystem über das Eintreffen eines Tastatur¬ 
zeichens. 

Port P21 fragt im ST die linke Maustaste bzw. den Fire-Button von Joystick #0 ab. Die rechte 
Maustaste bzw. Fire-Button von Joystick #1 wird über Port P22 erkannt. Die Tasten schließen 
bei Betätigung einen Kontakt nach Masse, so daß bei Betätigung ein Low am entsprechenden 
Portanschluß anliegt. 
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Abb. 7.7: Der Anschluß der intelligenten Tastatur an den ST 
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Und so funktioniert die Tastaturdekodierung: 

Der Tastaturprozessor legt nacheinander an jeden Port P31 ..P47 ein Low-Signai. Jede 
Spalte der Tastaturmatrix bekommt also einmal ein Low angeboten. 

- Wird eine Taste gedrückt, gelangt dieses Low an einen der Portanschlüsse P10...P17, 
welche als Eingang programmiert sind. Aus der Information, welche Spalte gerade ein 
Low erhält und welche Zeile dieses Low weitergibt, kann die gedrückte Taste in der 
Matrix ermittelt werden. Der entsprechende Tastencode (Make-Code) wird zum Tasta- 
tur-ACIA gesendet. 

Wenn die Taste wieder losgelassen wird, wird für die Taste ein sogenannter “Break- 
Code” gesendet (Break-Code = Make-Code .or. $80). 


Was macht die Maus? 

Port P20 ist im ST-Keyboard als Ausgang programmiert. Bei jedem Low an diesem Portaus¬ 
gang wird über den 8fach-Bustreiber (74LS244, siehe Abbildung 7.7) der Zustand der Maus¬ 
bewegungssensoren (oder Richtungsinformationen von den Joysticks) an die als Eingang pro¬ 
grammierten Ports P40..P47 gelegt. 

Die so gelieferten Daten der Mausbewegungssensoren werden mit den Daten aus der letzten 
Mausabfrage verglichen. Aus dem Unterschied zur vorhergegangenen Abfrage wird so die 
Bewegungsrichtung der Maus ermittelt. Die Richtungsinformation von den Joysticks (deren 
Richtungskontakte schließen gegen Masse) wird ebenfalls über Port P40..P47 abgefragt. 

Die Tastatur des 1040 ST unterscheidet sich ein klein wenig von der Tastatur der 260ST- und 
520STM-Computer. Zum einen wird die Verbindung zu den beiden Joystick- und Mausports 
nicht über eine Steckverbindung auf der Hauptplatine hergestellt, sondern direkt über zwei 
getrennte Verbindungsstecker. Weiterhin ist eine zusätzliche Leuchtdiode für das eingebaute 
Disklaufwerk (Floppy-Select-Indicator) vorhanden. 

Ebenso unterscheidet sich die Tastatur der MEGA-STs ein wenig von der Tastatur der anderen 
STs. Sie ist ja nun nicht mehr in das Gehäuse des Computers eingebaut, sondern davon abge¬ 
setzt und über ein flexibles Spiralkabel mit der Haupteinheit verbunden. 

Wie der Schaltplanauszug für den Anschluß der MEGA-ST-Tastatur verdeutlicht, werden 
außer den Leitungen für die Stromversorgung (+5V und Masse) nurnoch die TXD- (Transmit 
Data) und RXD-Leitung (Receive Data) benötigt. Die RESET-Leitung zum IKBD-Chip ist 
entfallen. Maus und Joysticks werden jetzt an der abgesetzten MEGA-ST-Tastatur ange- 
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schlossen. Durch die fehlende RESET-Leitung vom ST zum IKBD-Chip kann man nun eine 
“abgestürzte” MEGA-Tastatur nur noch durch einen Kaltstart (Computer ausschalten - etwas 
warten - Computer wieder einschalten) zur korrekten Funktion bewegen. 



+50 

+50 

™ an Tastatur 

GND 



ST und Tastatur 

(Ansicht auf! 
Cdie Buchse ] 


Abb. 7.8: So wird die Tastatur an den MEGA-ST angeschlossen 


Ein flinkes Tierchen am ST - Die Maus 

Erwähnt wurde sie ja schon bei der Beschreibung der intelligenten Tastatur - die Maus. Ohne 
sie wäre das Arbeiten nur halb so komfortabel (besonders bei Zeichen- und CAD-ähnlichen 
Programmen). 

Die Atari-Maus arbeitet nach dem opto-mechanischen Prinzip. Die Bewegungsinformation 
wird über eine Vollgummikugel auf zwei in Kugellagern laufende Walzen übertragen. Die 
Walzenachsen sind rechtwinklig zueinander angeordnet. Eine Walze wird also bei Bewegung 
in horizontaler Richtung (X-Richtung) und die andere bei vertikaler Bewegung (Y-Richtung) 
angetrieben. Auf jeder Walze sitzt nun eine Lochscheibe, welche bei Bewegung zyklisch den 
Lichtstrom zweier Lichtschranken unterbricht. Die beiden Lichtschranken sitzen sich auf der 
Lochscheibe genau gegenüber. 
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Abb. 7.9: Die optische Abtastung der Bewegung bei der Maus 


In der Lochscheibe befindet sich aber eine ungerade Zahl von Löchern, so daß beide Licht¬ 
schranken nie gleichzeitig unterbrochen werden. Tastet man nun die Ausgänge der 
Lichtschranken laufend ab, so kann aus der Information welche der beiden Schranken einer 
Achse zuerst unterbrochen wird, die Drehrichtung der Achse erkannt werden. Die Häufigkeit 
der Lichtstrahl-Unterbrechungen in einem Zeitintervall ist ein Maß für die Geschwindigkeit 
der Mausbewegung. Mit dieser verhältnismäßig einfachen Mechanik und Elektronik erzielt 
die Atari-Maus immerhin eine Auflösung von ca. vier Schritten/mm. Bewegungsgeschwindig¬ 
keiten bis zu 250 mm/Sekunde werden noch korrekt erfaßt. In Abbildung 7.10 ist die Schaltung 
der verhältnismäßig einfachen Mauselektronik dargestellt. Die Versorgungsspannung wird 
vom ST geliefert und ist in der Maus nochmals extra mit Glättungseikos gesiebt. 

Die von den Fototransistoren gelieferten Impulse werden über die als Schmitt-Trigger 
geschalteten Komparator-Stufen in “vernünftige”, steilflankige Rechteckimpulse umgewan¬ 
delt, mit denen der IKBD-Chip etwas anfangen kann. 

Als einziges “aktives” Bauelement (neben den LEDs und Fototransistoren) findet man in der 
Maus nur einen 4fach-Komparator (Spannungsvergleicher) des Typs “339”, allerdings in sei¬ 
ner “niedlichsten” Form, nämlich in der SMD-Ausführung (wie übrigens auch die verwende- 
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Abb. 7.10: Ohne sie läuft am ST nicht viel: die Maus 


ten Widerstände! Ja, ganz recht, was auf der Unterseite der Mausplatine so aussieht wie “Mäu¬ 
sedreck”, sind die SMD-Widerstände). 

(SMD = Surface-Mounted-Device = zu deutsch etwa: direkt mit der Platinenfläche verbun¬ 
denes Bauelement; SMDs werden ohne Anschlußdrähte direkt auf die Platinenoberfläche 
gelötet, was eine sehr kompakte Bauform ermöglicht.) 

In Abbildung 7,11 sind zur Verdeutlichung noch die Ausgangssignale der Komparatoren auf¬ 
geführt. Man erkennt deutlich, daß bei positiver Bewegungsrichtung der XA- (YA)-Ausgang 
eher High wird als der XB- (YB)-Ausgang. Bei negativer Bewegungsrichtung ist es dann 
genau andersrum. So erkennt der Tastaturprozessor dann die Bewegungsrichtung der Maus. 
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Abb. 7.11: Die Ausgangssignale der Mausbewegungssensoren 


Programmierung des IKBDs 

Der IKBD-Chip im ST kommuniziert mit seiner Umwelt, wie bereits weiter vom gesehen, 
über eine eigene serielle Schnittstelle und kann darüber auch Daten empfangen. 

Kommandos an den IKBD kann man sehr leicht mittels der XBios-Funktion “Dcbdws” über- 
tragen. Mit dem Empfangen der Daten ist es schon erheblich komplizierter: Dazu muß man 
sich zunächst mittels der XBios-Funktion “Kbdvbase” die Adresse der Tabelle der IKBD- 
Routinen besorgen. Jenachdem, ob man Uhrzeit-, Maus-, Joystick-, Tastatur- oder Statusinfor- 
mationen abfragen will, muß man an der entsprechenden Stelle seine eigene Empfangsroutine 
einsetzen. Nur so ist es beispielsweise möglich, dielBKD-Uhrzeitim 1-Sekunden-Takt abzu¬ 
fragen, denn XBios wirft bei der eigenen Abfrage jeweils das unterste Bit weg, um auf das MS/ 
DOS- und GEMDOS-spezifische Datumsformat zu kommen, 

Daten werden auf zwei verschiedene Arten empfangen. Da wären zunächst die Meldungen 
über das Drücken und Loslassen von Tasten, für die die Werte 0 bis 117 (+128 beim Loslassen 
der Taste) reserviert sind (die IKBD-eigenen Codes, auch Scancodes genannt, finden Sie im 
Anhang). Weitere Codes leiten jeweils ein sogenanntes “Datenpaket” ein, das mehrere Bytes 
umfassen und verschiedenste Informationen enthalten kann. Nun jedoch zu den einzelnen 
IBKD-Funktionen: 


Reset (IBKD $80, $01) 

Schaltet den IKBD-Chip in den Anfangszustand zurück. Dabei geht die Uhrzeit nicht verloren 
(das passiert nur bei Unterbrechung der Stromzufuhr). Außerdem wird ein Keyboard-Selbst- 
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fest durchgeführt, dessen Erfolg durch den Wert $F1 zurückgemeldet wird. Dabei wird die 
angeschlossene Tastatur auf Funktionstüchtigkeit getestet. So wird dann für jeden geschlos¬ 
senen Tastenkontakt angenommen, daß die betreffende Taste defekt ist. Für alle solche Tasten 
wird der Break-Code gesendet (das heißt, es wird ein Loslassen dieser Taste gemeldet). Dieser 
Selbsttest wird in der momentanen Version von TOS ignoriert. 

Set mouse button action (IKBD $07, Modus) 

Mit diesem Kommando kann man festlegen, wie die beiden Tasten der Maus behandelt werden 
sollen. Dabei kann man einerseits die Maustasten wie “Alt/Insert” und “Alt/ClrHome” behan¬ 
deln lassen oder festlegen, ob eine Meldung bei Drücken oder Loslassen der Maustaste gesen¬ 
det werden soll (die beiden untersten Bits sind nur im absoluten Modus relevant, der Standard¬ 
wert für Modus ist 0): 

Modus = 4: Maustasten wie Tastatur behandeln 
Modus = 2: Loslassen der Maustaste melden 
Modus = 1: Drücken der Maustaste melden 

Set relative mouse position reporting (IKBD $08) 

Schaltet den relativen Mausbewegungsmodus ein, der auch der vom AES benutzte Standard¬ 
modus ist. In dieser Betriebsart wird immer dann ein Mausereignis gemeldet, wenn die Maus 
um einen mittels “Set mouse threshold” festlegbaren Betrag bewegt oder eine der Maustasten 
gedrückt wurde. Geliefert werden Status-Pakete folgender Form: 

typedef struct 
1 

har header; /* 0xF8 bis OxFB - die beiden untersten Bits 
geben den Status der Maustasten an */ 
char dx,dy; /* Relative Position, zwischen -128 und 127 */ 

} RELMAUS; 

Sollte der Darstellungsbereich von -128 bis 127 für die erfolgte Mausbewegung nicht ausrei¬ 
chen, dann wird ein weiteres Paket geschickt. 


Set absolute mouse positioning (IKBD $09, xmax, ymax) 

Schaltet auf den absoluten Mausbewegungsmodus. In dieser Betriebsart meldet der IKBD, der 
Mausposition entsprechend, absolute Koordinaten. Dazu muß man in den beiden 16-Bit-Wer¬ 
ten xmax und ymax die Maximalzahl für die beiden Koordinatenrichtungen angeben. Bewe¬ 
gungen unterhalb der Nullposition und oberhalb der angegebenen Grenzen werden ignoriert. 
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Set mouse keycode mode (IBRD $A, dx, dy) 

In dieser Betriebsart kann man mit der Maus das Drücken der Cursor-Tasten emulieren (das 
bietet sich bei allen TOS-Applikationen mit Cursor-Steuerung an. Aus einem biederen Screen- 
Editor wird damit ein rasantes Mausprogramm!). Als Parameter muß man die Anzahl von 
horizontalen bzw. vertikalen Koordinatenschritten angeben, die je einem Tastendruck ent¬ 
sprechen sollten (10 ist dafür ein brauchbarer Wert). 

Set mouse threshold (IKBD $B, x, y) 

Setzt die Ansprechschwelle für Mausbewegungen für beide Richtungen separat (nur für den 
relativen Modus relevant). Standardwert nach RESET ist 1. 

Set mouse scale (IKBD $C, x, y) 

Hiermit kann die Maus-Skalierung für beide Richtungen gesetzt werden. Man legt fest, um 
wieviel die Maus bewegt werden muß, damit die IKBD-intemen Positionszähler um 1 erhöht 
bzw. vermindert werden. Dieser Befehl kann nur für den absoluten Modus benutzt werden. 

Interrogate mouse Position (IKBD $D) 

Im absoluten Modus kann hiermit die Position der Maus abgeffagt werden. Der IKBD liefert 
ein Statuspaket folgenden Formats zurück: 

typedef struct 
{ 


char header; 

/* 

0xF7 = absolute mouse position header */ 

char buttons; 

/* 

Status der Mausknöpfe */ 

int x; 

/* 

X-Koordinate */ 

int y; 

/* 

Y-Koordinate */ 


} ABSMMJS; 

In “buttons” werden die untersten vier Bits folgendermaßen benutzt: 

Bit 0: rechter Knopf seit letzter Abfrage gedrückt 
Bit 1: rechter Knopf seit letzter Abfrage losgelassen 
Bit 2: linker Knopf seit letzter Abfrage gedrückt 
Bit 3: linker Knopf seit letzter Abfrage losgelassen 

Load mouse position (IKBD, $E, $0, x, y) 

Im absoluten Modus kann man mit diesem Kommando die internen Koordinaten-Zähler des 
IBKD setzen (x und y sind 16-Bit-Werte!). 
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Set Y=0 at bottom (IKBD $F) 

Setzt die Orientierung der Y-Achse (Y vermindert sich, wenn die Maus vom Anwender 
zurückgezogen wird). 

Set Y=0 at top (IKBD $10) 

Setzt die Orientierung der Y-Achse auf den Standardwert (Y erhöht sich, wenn die Maus “nach 
unten” gezogen wird). 

Resutne (IKBD $11) 

Mit diesem Kommando kann der Datentransfer vom IKBD wieder gestartet werden, nachdem 
er mittels “Pause output” gestoppt worden war. 

Da der IKBD sowieso bei Erhalt eines Kommandos die Datenübertragung startet, ist “Re- 
sume” eigentlich nur ein NOP-Befehl (No Operation). 

Disable mouse (IKBD $12) 

Schaltet die Mausabfrage ab, die mit “Set relative mouse position reporting", “Set absolute 
mouse positioning” oder “Set mouse keycode mode” wieder gestartet werden kann. 

Pause output (IKBD $13) 

Stoppt die Datenübertragung vom IKBD zum ST, bis ein neues gültiges Kommando (wie zum 
Beispiel “Resume”) empfangen wird. So weit es die Buffer im IKBD zulassen, werden alle 
Meldungen gebuffert und dann bei der Fortsetzung der Übertragung gesendet. 

Set joystick event reporting (IKBD $14) 

Schaltet den Joystick-Ereignis-Modus ein (Standardeinstellung). In diesem Modus wird je¬ 
desmal, wenn ein Joystick-Kontakt geöffnet oder geschlossen wurde, ein entsprechendes Sta¬ 
tuspaket gesendet. 

typedef struct 

( 

char header; /* SFE Joystick 0, $FF Joystick 1 */ 

char val; /* Bits 0-3 für die vier Bewegungsrichtungen, 

Bit 7 für den Feuerknopf */ 


} JOYEVENT; 
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Set joystick interrogation mode (IKBD $15) 

Schaltet die automatische Meldung von Joystick-Ereignissen ab. In diesem Modus muß man 
für jede Joystickabfrage ein spezielles Kommando (“Joystick Interrogation”) senden. 

Joystick interrogation (IKBD $16) 

Diese Funktion kann in beiden Joystick-Abfrage-Modi benutzt werden und liefert ein Joy¬ 
stick-Statuspaket 

Set joystick monitoring (IKBD $17, rate) 

In diesem Betriebsmodus wird in bestimmten Zeitabständen (berechnet sich zu Rate/100 in 
Sekunden) der Status der Joysticks gemeldet. Alle anderen Aktivitäten werden gestoppt. Die 
Statuspakete von zwei Bytes Länge haben folgende Form: 

1. Byte: BitO: Feuerknopf Joystick 1 

Bit 1: Feuerknopf Joystick 0 

2. Byte: Bit 0-3: Richtungen Joystick 1 

Bit 4-7: Richtungen Joystick 2 

Set fire button monitoring (IKBD $18) 

In diesem Modus wird permanent der Status des Feuerknopfs von Joystick 1 gemeldet. Die 
Daten werden in gepackter Form in Bytes gesendet (also immer acht Werte innerhalb eines 
Bytes). Die Abfragerate ist ungefähr so groß, daß in derselben Zeit, in der auch ein Byte 
gesendet wird, wieder acht neue Werte abgefragt werden. Daher sollte man die ankommenden 
Bytes möglichst in konstanten Abständen abrufen. 

Set joystick keycode mode (IKBD $19, rx, ry, tx, ty, vx, vy) 

In diesem Betriebsmodus wird mit Joystick 0 (also einem Joystick, der im Mausport steckt) 
die Cursor-Tastatur emuliert. Dabei handelt es sich bei den sechs Parametern um Zeitangaben 
in 1/10 Sekunden für die beiden Richtungen, Mit Schließen eines Joystick-Kontakts beginnt 
ein interner Zähler zu laufen. Die Arbeitsweise sei an folgendem Beispiel für die X-Richtung 
veranschaulicht (r=6, t=2, v=l): 

Zeit (1/10 sec) Tastendruck 


0 

1 


(1) <- Intervalle von t/10 
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Zeit (1/10 sec) 

Tastendruck 

2 

(2) 

3 

- 

4 

(3) 

5 

- 

6 

(4) <- Ablauf von r/10, nun Intervalle von v/10 

7 

(5) 

8 

(6) 

9 

(7) 

10 

(8) 


So läßt sich sehr leicht eine Autorepeat-Funktion erreichen. Ist dieser Effekt nicht erwünscht, 
dann kann man “rx” bzw. “ry” auf 0 setzen. 

Disable Joysticks (IKBD $1A) 

Joystickabfrage beenden. Sie kann mit irgendeinem gültigen, den Joystick betreffenden 
Kommando wieder in Gang gesetzt werden. 

Time-of-day clock set (IKBD $1B, j'ahr, rnonat, tag, stunde, minute, sec) 

Setzt die Uhr im IKBD-Chip. Jeder der sechs Parameter ist eine zweistellige, gepackte BCD- 
Zahl. 

Beispiel: tag=31 für den 31. eines Monats 

Jeder einzelne Wert wird separat auf Plausibilität geprüft. Gibt man beispielsweise für den 
Monat eine 13 an, wird das Monatsfeld nicht geändert. Akzeptiert wird dagegen ein Datum 
wie der 30.02.1987! 

Interrogate time-of-day clock (IKBD $1C) 

Fragt die Uhrzeit des IKBD-Chips ab. Als Resultat wird ein Statuspaket folgender Art 
gesendet: 

typedef struct 

{ 

char header; /* $FC, Uhrzeit-Statuspaket */ 
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char jahr; 
char monat; 
char tag; 
char stunde; 
char minute; 
char sec; 

} TIMEOFDAY; 


/* Jahreszahl in gepackter BCD-Form */ 

/* Monatszahl in gepackter BCD-Form */ 

/* Tageszahl in gepackter BCD-Form */ 

/* Stundenzahl in gepackter BCD-Form */ 
/* Minutenzahl in gepackter BCD-Form */ 
/* Sekundenzahl in gepackter BCD-Form */ 


Memory load (IKBD $20, adresse, anzahl, (daten)) 

Mit dieser Punktion kann man das RAM des IKBD beschreiben (der RAM-Bereich “erstreckt” 
sich über den Bereich von $80 und $FF). Dazu übergibt man in “adresse” (16 Bit) die ge¬ 
wünschte Adresse und in “anzahl” die Zahl der zu übertragenden Bytes. Es folgen dann die 
einzelnen Bytes, wobei der Zeitabstand zwischen den einzelnen Datenbytes maximal 20ms 
betragen darf. (Null-Bytes können wegen eines Fehlers im KBD-Betriebssystem nicht über¬ 
tragen werden!) 

Memory read (IKBD $21, adresse) 

Mit dieser Funktion kann man den Speicher des IKBD auslesen. Als Parameter übergibt man 
die gewünschte Anfangsadresse als 16-Bit-Wert, Der IKBD liefert daraufhin folgendes Daten¬ 
paket: 

typedef struct 
{ 

char headerl; /* $F6 - Header für Statuspakete */ 

char header2; /* $20 - Header für Memory read */ 

char data[6]; /* 6 Bytes Speicherinhalt ab adresse */ 

} MEMREAD; 

Controller execute (IKBD $22, adresse) 

Startet ein Unterprogramm (beginnend bei “adresse”, 16-Bit) im IKBD. Um diesen Befehl zu 
nutzen, müßte man natürlich das Betriebssystem des IKBD kennen oder selbst ein Programm 
in den “freien” Speicher übertragen haben... 


Status inquiries (IKBD $87-$9A) 

Mit Hilfe der Statusabfrage-Kommandos kann man den IKBD auffordem, jeweils den Status 
verschiedener Betriebszustände zurückzumelden. Das Kommando entspricht jeweils einem 
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der betreffenden SET-Komrnandos mit gesetztem achten Bit. Als Resultat liefert der IKBD 
immer ein 8-Byte-Paket folgender Form: 

typedef struct 

l 

char header; /* 0xf6 = Status inquiry header */ 

char vals[7]; /* Fünf weitere Werte */ 

} IKBDSTAT; 

Das erste Byte dieser Datenstruktur ist immer das Headerbyte $F6. Die Bedeutung der restli¬ 
chen sieben Bytes ist für die einzelnen Abfrage-Kommandos jeweils verschieden. Sollten 
weniger als sieben Bytes belegt sein, dann wird mit Nullen aufgefüllt. 

Das Statuspaket ist so geformt, daß die eingegangene Statusmeldung (unter Weglassen des 
Header-Bytes) direkt wieder an den IKBD geschickt werden kann. Eventuell abschließende 
Nullen werden dabei vom IKBD ignoriert. Im folgenden wird jeweils die Belegung des vals[]- 
Arrays angegeben. 

Request mouse button action (IKBD $87) 

Fragt den Maustastenmodus ab. Liefert {7, Modus, 0, 0,0, 0,0 }. 

Request mouse mode (IKBD $88, IKBD $89, IKBD $8A) 

Fragt den aktuellen Mausbewegungsmodus ab. 

Im relativen Modus: {8,0,0,0,0,0,0} 

Im absoluten Modus: (9,xmax (MSB),xmax (LSB),ymax (MSB).ymax (LSB),0,0} 

Im Keycode-Modus: (10,dx,dy,0,0,0,0) 

Wie man sieht, kann man die sieben Bytes, die man nach dem Statusbyte erhält, direkt als 
Kommando für den IKBD “recyceln”. 


Request mouse threshold (IKBD $8B) 

Fragt die Ansprechschwelle für Mausbewegungen im relativen Modus ab. Liefert 
{1 l,x,y,0,0,0,0). 

Request mouse scale (IKBD $8C) 

Fragt die Maus-Skalierung ab. Liefert {12,x,y,0,0,0,0}. 
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Request mouse vertical Coordinates (IKBD $8F, IKBD $90) 

Liefert { 15,0,0,0,0,0,0 1 für Y=0 am unteren Rand und ( 16,0,0,0,0,0,0 ) für Y=0 am 
oberen Rand. 

Request mouse avaiiability (IKBD $92) 

Liefert { 0, 0, 0, 0,0, 0,0 } bei eingeschalteter Maus und sonst ( 18,0, 0, 0, 0, 0,0 }. 

Request joystick mode (IKBD $94, IKBD $95, IKBD $99) 

Fragt den aktuellen Joystick-Modus ab. Liefert (20,0,0,0,0,0,0} für den normalen Modus 
(“event reporting”), {21,0,0,0,0,0,0} für den Nachfrage-Modus (“joystick interrogation 
mode”) oder {25,rx,ry,tx,ty,vx,vy} für den Keycode-Modus. 

Request joystick avaiiability (IKBD $9A) 

Liefert {0,0,0,0,0,0,0} bei eingeschalteter Joystick-Abfrage und sonst (26,0,0,0,0,0,0). 

Wer sich genauer mit dem Innenleben des Tastaturprozessors auseinandersetzen will, sei auf 
die Artikelserie “Licht in die Geheimnisse des Tatstaturprozessors” in der ST-Computer 3/ 
90..5/90 hingewiesen. Beim Autor Sieghard Schäfer (Hallo Sieghard! Hat mir gut gefallen die 
Serie) kann man auch ein disassembliertes und kommentiertes Listing vom IKBD-Betriebs- 
system erhalten. 
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Kapitel 8: Das Floppy-Disk-Interface 


Die ATARI ST-Computer haben alle nötige Hardware zur Steuerung von Floppy-Disk- 
Laufwerken bereits im Grundgerät integriert. Bei den Computern des Typs ATARI 1040STF 
und den MEGA STs ist außerdem ein Disklaufwerk eingebaut. 

Serienmäßig werden von ATARI für die ST-Computer 3,5-Zoll-Disklaufwerke verwendet. 
Diese Laufwerke ermöglichen heute eine Speicherkapazität von mindestens 720 KByte je 
Disk bei einer kleinen, kompakten und gegen äußere Einflüsse relativ gut geschützten 
Bauform (unbeabsichtigtes Verknicken und Verschmutzen und Beschädigungen durch knab¬ 
bernde Wellensittiche und Kanarienvögel werden wirkungsvoll verhindert.) 

Für die Computer der ST-Serie wird inzwischen nur noch das zweiseitige Disklaufwerk 
angeboten. Zur Datenspeicherung wird die Vorder- und Rückseite der Diskette verwendet. Die 
Daten werden hierbei in 80 Spuren (Tracks) auf der Diskette verstreut. Jede Spur ist in neun 
Sektoren mit je 512 Bytes Datenkapazität aufgeteilt. 


Die Datenspeicherung auf Diskette 

Die auf einer Disk gespeicherten Informationen sind eine Aneinanderreihung von in verschie¬ 
denen Richtungen magnetisierten Partikeln in der Magnetschicht der Diskette. Man kann sich 
das als eine Aneinanderreihung von winzig kleinen “Stabmagneten” vorstellen, die kreisförmig 
in einer Spur auf der Diskette Pol an Pol liegen. 

Eine solche Spur dreht nun mit 300 Umdrehungen/Minute unter dem Schreib-/Lesekopf des 
Disklaufwerks. Die unter dem Kopf vorbeirotierenden “Stabmagnete” bewirken, abhängig 
von ihrer Magnetisierungsrichtung, in dem Kopf Magnetfeldschwankungen, welche zu 
Stromschwankungen führen, die dann von der Lese-Elektronik ausgewertet werden können. 
Die Lese-Elektronik im Laufwerk wandelt diese Stromschwankungen in einen seriellen Bit¬ 
strom um, der zum ST gesendet wird. So werden Informationen von Diskette gelesen. Beim 
Beschreiben von Disketten geht man den umgekehrten Weg: 

Ein serieller Bitstrom vom ST wird durch die Schreib-Elektronik im Laufwerk in gezielte 
Stromänderungen für den Schreib-/Lesekopf umgewandelt. 

Die durch die Stromänderungen hervorgerufenen Magnetfeldschwankungen magnetisieren 
die Magnetschicht (die kleinen Stabmagnete) auf der Disk in die gewünschte Richtung und 
legen so die Informationen dauerhaft dort ab. Dauerhaft aber nur so lange, bis man die Diskette 
mit dem gerade fertigprogrammierten Superutility nachts um zwei Uhr erschöpft auf die 
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gestern neu erworbenen Autolautsprecher mit den neuen extra starken Permanentmagneten 
legt, die man am Wochenende unbedingt noch einbauen will. 

Wahrscheinlich werden die kleinen Stabmagnete auf der Disk dann wohlgeordnet in einer 
Richtung angeordnet sein. Nämlich in jene, in die sie durch das äußere Magnetfeld der Laut¬ 
sprechermagnete gequetscht wurden. 

Kurzum, den gleichen Effekt hätte man auch durch Formatieren der Disk erreicht, die Daten 
(und damit das Superutility) sind futsch! Also Vorsicht vor fremden Magnetfeldern! 


Präzision ist gefragt 

Wer schon mal den Metallschuber der 3,5-Zoll-Diskette vorsichtig beiseite geschoben hat 
(Achtung bei umherfliegenden Kanarienvögeln und Wellensittichen, sie lassen meist in dem 
Moment etwas hinter sich, in dem man es nicht erwartet, und treffen dann auch noch genau!), 
wird den ca. 10 x 24 mm 2 großen Ausschnitt in der Diskettenhülle gesehen haben. 

In diesem kleinen Ausschnitt bewegt sich der Schreib-/Lesekopf des Laufwerks vom Außen¬ 
rand der Disk zur Mitte und wieder zurück, um die richtige Spur mit den Daten zu finden! 

Wie schon kurz erwähnt, sind auf einer solchen Disk 80 Spuren vorhanden, die der Kopf 
“anfahren” können muß (auch wenn man mit manchen Laufwerken mehr als 80 Spuren ansteu- 
em kann; Atari garantiert für seine Drives nur maximal 80 Spuren!). Diese 80 Spuren verteilen 
sich auf eine S panne von ca. 15 mm. Eine Spur ist also nur ca. 0,19 mm breit! Man sieht daran, 
mit welch einer Präzision die Mechanik einer solchen Diskstation arbeiten muß. 

Der Schreib-/Lesekopf wird auf einem sogenannten Kopfschlitten geführt. Die Positionierung 
des Schlittens erfolgt durch einen Schrittmotor, welcher den Kopfschlitten Schritt für Schritt 
hin und her bewegen kann. Der Wechsel von einer Spur zur benachbarten Spur geschieht bei 
den 3,5-Zoll-Laufwerken üblicherweise in nur 3 Millisekunden! 

Die Spuren auf der Diskette werden von außen nach innen durchnumeriert. Die äußere Spur 
hat die Nummer 0, die innerste Spur trägt die Nummer 79. Jede Spur enthält ca. 6250 Bytes 
an Informationen. 


Und wo fängt man an? - Der Indeximpuls 

Für die Anfangsmarkierung einer Spur (wo fängt ein Kreis an?) sorgt der sogenannte 
Indeximpuls. Er wird einmal pro Umdrehung an immer der gleichen Stelle der Spur vom 
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Laufwerk erzeugt. Das geschieht durch Abtastung mittels eines Sensors am Antriebselement 
des Disklaufwerks. 

Die neun Sektoren/Spur (9x512 = 4608 Bytes) werden von 1..9 durchnumeriert und sind in 
den möglichen 6250 Bytes eines Tracks eingebettet. “Umrahmt” werden die neun jeweils 512 
Bytes langen Sektoren einer Spur von Synchronisations-und Informationsbytes für Spumummer, 
Sektornummer, Prüfsummen usw. 


Struktur ist wichtig! - Das Track-Layout der ST-Floppies 

Die auf Disk abzulegenden Daten werden in Blöcken zu 512 Bytes (Sektoren) angeordnet. 
Damit der FDC (das ist der Floppy-Disk-Controller; er ist der Dolmetscher zwischen CPU und 
Laufwerken) jedoch weiß, über welcher Stelle auf der Diskette sich der Kopf gerade befindet, 
ist es erforderlich, eine bestimmte Struktur auf die Diskette aufzubringen. Es sind Markierun¬ 
gen (Nachgucken lohnt auch mit Lupe nicht, markiert wird magnetisch!) erforderlich, aus de¬ 
nen zu erkennen ist, wo eine Spur beginnt, über welcher Spur (Track) sich der Kopf gerade 
befindet, welcher Sektor gerade vorbeirotiert, wo die Daten im Sektor anfangen bzw. aufhören 
usw. 

Das beim ATARI ST verwendete Tracklayout ist in Abbildung 8.1 zur besseren Übersicht 
schematisch dargestellt. 

Ein Track beginnt mit 60 Bytes $4E, welche dem Datenseparator (der sitzt im FDC und bröselt 
den vom Laufwerk eintreffenden Bitstrom in Daten- und Taktinformationen auf) im FDC dazu 
dienen, sich auf den einlaufenden Bitstrom vom Laufwerk zu synchronisieren. Das mit dem 
Synchronisieren ist eine aufwendige Sache, denn der Bitstrom kommt natürlichmit Geschwin- 
digkeitsschwankungen daher. Die Disk rotiert ja auch nicht immer mit konstanter Geschwin¬ 
digkeit!) 

Jeder Sektorbeginn wird durch 12 Bytes $00, gefolgt von 3 Bytes $A1 (mit fehlenden 
Taktimpulsen, deshalb für den FDC besonders auffällig!), angekündigt. Es folgt ein Byte mit 
$FE (ID-Address Mark), welches dem FDC den Beginn eines Sektor-Headers signalisiert. 

Dieser Sektor-Header enthält je ein Byte für die Spumummer ($00.. .$4F), Seitennummer ($00 
oder $01), Sektomummer ($01...$09) und ein Byte für die Sektorgröße ($02 weist auf 512 
Bytes/Sektor hin). Danach folgen zwei Bytes mit einer Prüfsumme über die vorangegangenen 
4 Bytes des Sektor-Headers. 

Anschließend wird der Datenseparator des FDC wieder mit 22 Bytes $4E und 12 mal $00 zur 
Synchronisation gefüttert. 
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Abb. 8.1: Das Track-Layout beim ST 


Drei Bytes $A1 (mit fehlenden Taktimpulsen), gefolgt von einem $FB (die “Data-address- 
mark”, kurz: DAM), leiten dann die eigentlichen 512 Datenbytes des Sektors ein. Diesen folgt 
natürlich wieder eine Prüfsumme in Form zweier CRC-Bytes (CRC = Cyclic Redundancy 


Wiederholt sich für Jeden SektorC614 ButesJ 



















Das Floppy-Disk-Interface 


949 


Checking, zu deutsch etwa: zyklische Blockprüfung. Ein Datenblock wird einer laufenden 
Prüfzeichenbildung unterzogen. Die gewonnene Prüfinformation wird vom FDC als 2 x 8 Bit- 
Wert abgelegt.). 

Bis zu Beginn des nächsten Sektors folgen dann 40 Bytes mit $4E (damit der FDC nicht aus 
dem Tritt kommt). Dieses Raster wird bei der Formatierung einer Diskette aufgebracht. Hieran 
läßt sich erkennen, daß so ein FDC eine Menge Dekodierarbeit zu leisten hat, bevor dann 
endlich die “reinen” Datenbytes zur Verfügung stehen. 

Ist die Diskette jedoch erstmal auf diese Weise formatiert, erfolgen alle weiteren Zugriffe nur 
noch im Sektorformat. Die Markierungen und Lückenbytes auf der Disk werden ebenso wie 
der Sektor-Header nun nicht mehr angetastet. 

Das Datenfeld eines Sektors wird vielfach wieder geändert, wobei eine Modifizierung immer 
ein komplettes Neubeschreiben des entsprechenden Sektors mit den geänderten Daten erfor¬ 
dert. Die CRC-Bytes nach jedem Datenfeld werden natürlich bei Veränderungen von Daten¬ 
bytes im Sektor ebenfalls jedesmal neu berechnet und geschrieben. 


Alles unter Kontrolle!? - Was der Floppy-Controller 
können muß 

Für den Datenaustausch von Daten zwischen Computer und Diskstation sind eine Vielzahl von 
Funktionen auszuführen und KontrollSignale vom Laufwerk zu überwachen. 

Um die CPU von dieser Arbeit ffeizuhalten, werden die Floppy-Disk-Controller (FDC) ein¬ 
gesetzt. Diese hochintegrierten B austeine sind speziell für die Ansteuerung von Disklaufwerken 
entwickelte Chips. Sie sind selbst Mikrocomputer, die jedoch nur Disklaufwerke steuern kön¬ 
nen. Diese Aufgabe beherrschen sie dafür aber meisterhaft. Um zu sehen, was ein solcher 
Floppy-Disk-Controller alles können muß, werfen wir mal einen Blick auf die Anschlüsse, die 
ein Disklaufwerk so aufweist. 

Zum Glück (oder sollten da die Hersteller etwa voneinander abgekupfert haben?) hat sich bei 
den Anschlüssen für die Disklaufwerke bei allen Herstellern so eine Art Anschluß-Norm 
durchgesetzt. Außer den normalen Anschlüssen für die Stromversorgung des Laufwerks 
(+12V, +5Vund Masse; es gibtauch bereits Laufwerke, die mitnur einerVersorgungsspannung 
von 5 Volt arbeiten), gibt es für die Daten- und Steuerleitungen den sogenannten Shugart-Bus. 

Hierbei handelt es sich um eine 34pol. Flachbandkabel-Verbindung über Pfostenfeld-Steck¬ 
verbinder (dies gilt für 3,5 Zoll-Laufwerke, bei 5,25-Zoll-Laufwerken findet man eine Steck- 
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Verbindung, die direkt auf die Laufwerksplatine gesteckt wird). Am 3,5-Zoll-Laufwerk befin¬ 
det sich dabei die Stiftleiste, folglich sitzt am Anschlußkabel die zugehörige 34pol. Buchsenleiste. 
Wie Abbildung 8.2 zeigt, sind jedoch nicht alle 34 Anschlüsse mit verschiedenen Signalen be¬ 
legt. Zur Unterdrückung von Störimpulsen ist fast jede zweite Leitung auf Masse gelegt. 
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So sieht die Aufsicht 
auf den Steckverbinder 
zun Disklaufwerk aus! 
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Abb. 82: So sieht der normale Shugart-Bus für 3,5-Zoll-Laufwerke aus 


Weiterhin gibt es keine Leitungen für beide Signalrichtungen. Jedes Signal wirkt immer nur 
in eine Richtung, entweder vom FDC zum Laufwerk oder vom Laufwerk zum FDC. Hier nun 
eine kurze Beschreibung der Anschlüsse, beginnend mit den 12 Signalleitungen vom FDC 
zum Laufwerk. 

Density* (Pin 2) Im ST nicht benutzt (im TT und Mega STE schon)! Die modernen 

High-Density-Laufwerke weisen diesen Anschluß auf (mit HD- 
Laufwerken und speziellen HD-Disketten kann man durch Erhö¬ 
hung der Taktrate 2 um Lesen/Schreiben 18 Sektoren/Spur unter¬ 
bringen. Damit ergibtsich eine Speicherkapazität von 1,44 MByte!). 
Verwendet wird der Anschluß, je nach Jumpereinstellung auf dem 
Laufwerk, als Eingang oder Ausgang. 
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Als Ausgang: Das Laufwerk signalisiert dabei über den Anschluß 
dem Computer, welche Art von Disk eingelegt ist. HD-Disks wer¬ 
den dabei durch eine zusätzliche Öffnung in der Diskhülle er¬ 
kannt! Welcher Logikpegel für die Signalisierung von HD-Be- 
trieb verwendet wird, läßt sich ebenfalls über Jumper am Laufwerk 
einstellen. 

Als Eingang: In dieser Betriebsart “sagt” der Computer, welche 
Betriebsart das Laufwerk einzustellen hat. Bei welchem Logikpegel 
HD-Betrieb “gewünscht’ ’ wird, ist wieder über Jumper konfigurier¬ 
bar! 

Head load (Pin 4) ImSTnichtbenutztlEinLowsignalisiertderLaufwerkselektronik 

“Kopf ab”, d. h., der Schreib-/Lesekopf soll auf die Disk abge¬ 
senkt werden. Bei 5,25-Zoll-Drives wird dieser Anschluß noch 
manchmal benutzt, während er bei 3,5-Zoll-Laufwerken seltener 
anzutreffen ist. Hat man ein Laufwerk mit “Head load” anzuschlie¬ 
ßen, so kann man den Anschluß mit dem “Motor on”-Anschluß 
verbinden! So wird “Head load” aktiviert, sobald der Motor ge¬ 
startet wird. Beim Ansprechen von Drives mit “Head load” sollten 
FDC-Kommandos mit gesetztem E-Bit gegeben werden, um dem 
Laufwerk Zeit zu geben, den Kopf abzusenken. 

Drive sei. A..D (Pin 10,12,14,6) 

Über diese Signalleitungen bekommt die Laufwerkselektronik 
mitgeteilt, welches Laufwerk gerade angesteuert wird. Das Signal 
ist Low-aktiv, d. h., ein Low-Pegel auf der entsprechenden Lei¬ 
tung wählt das gewünschte Laufwerk an. Atari benutzt nur Drive 
select A und B! 

Side select (Pin 32) Bei High-Pegel wird auf Seite 0 (Vorderseite) der Disk gearbeitet. 

Sobald hier Low anliegt, bekommt der Sehreib-/Lesekopf auf der 
Seite 1 (Rückseite) Arbeit. 

Motor on (Pin 16) Ein Low-Pegel startet den Motor (immer! Egal, ob das Laufwerk 

selektiert ist oder nicht!) 

Write gate (Pin 24) Signalisierung an die Laufwerkselektronik: 


High: Daten werden gelesen. 

Low : Daten werden geschrieben. 
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Write Data (Pin 22) Der FDC sendet über diese Leitung die zu speichernden Daten in 
einem seriellen Bitstrom. Die Laufwerkselektronik setzt diesen 
Datenstrom in entsprechende Magnetfeldschwankungen im 
Schreib~/Lesekopf um. 

Step direction (Pin 18) Die Richtung, in welcher der Kopf bewegt werden soll, wird hier¬ 
mit festgelegt. 

High: Schrittbewegung nach außen (niedrigere Spumummer) 
Low : Der Kopf soll nach innen (höhere Spumummer) 

Die eigentliche Schrittbewegung wird jedoch erst durch das Si¬ 
gnal “Step” ausgelöst! 

Step (Pin 20) Jeder Low-Impuls bewegt den Kopf einen Schritt in die durch 

“Step direction” vorgewählte Richtung. 

Nun zu den Signalen, die vom Laufwerk an den FDC gerichtet sind: 

Write protect (Pin 28) Ein High signalisiert dem FDC, daß die Diskette beschrieben wer¬ 

den kann. Bei Low ist das Schreiben auf Disk gesperrt. Für die 
Signalisierung wird das Write protect-Fenster in der Diskette 
durch eine Lichtschranke abgefragt. 

Track 00 (Pin 26) Wenn der Kopf auf Spur 00 positioniert ist, geht dieses Signal auf 

Low-Pegel. Sonst liegt hier High. 

Index (Pin 8) Bei jeder Diskettenumdrehung wird ein kurzer Low-Impuls er¬ 

zeugt. Dies geschieht immer an der gleichen Stelle einer Umdre¬ 
hung und dient zur Markierung des Spuranfangs. 

Read Data (Pin 30) Beim Lesen von Daten (‘.‘Write gate” auf High) liefert die Lauf¬ 
werkselektronik an diesem Anschluß einen Bitstrom mit Daten 
von der Diskette. Für die Entwirrung dieses Datenstroms, der Da¬ 
ten- und Taktinformationen enthält, und die Umsetzung in Daten¬ 
bytes ist der FDC zuständig. Der Bitstrom ist durch Drehzahl¬ 
schwankungen des Diskantriebs nicht immer gleichmäßig, son¬ 
dern unterliegt Schwankungen, die der FDC bei der Decodierung 
berücksichtigen muß. 


Ready (Pin 34) 


Hierüber wird dem FDC mit einem Low signalisiert, daß das 
angesprochene Laufwerk bereit zur Arbeit ist. Das ist dann der 
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Fall, wenn eine Disk eingelegt ist. Deshalb wird das Ready-Signal 
auch verschiedentlich für die Diskwechsel-Erkennung benutzt. 
Beim ST wird der Anschluß jedoch nicht verwendet. 

Dürfen’s ein paar Leitungen weniger sein? 

Die Konstrukteure des ST waren wohl der Meinung, daß 34 Leitungen viel zuviel sind. 
Außerdem sorgt ein “eigenes” Steckerformat dafür, daß bevorzugt die von Atari produzierten 
Diskstationen verkauft werden. Wohl deshalb werden die Diskstationen an den ST über ein 
14pol. Anschlußkabel mit einem 14pol. Stecker in der Form der heute üblichen DIN-Stecker 
angeschlossen. 

Beim Öffnen eines originalen Atari-Laufwerks stellt man dann jedoch fest, das im Gehäuse 
der Diskstation wieder eine Umsetzung vom Atari-Steckerformat auf den gebräuchlichen 
34poligen Steckanschluß erfolgt. Die Abbildung 8.3 zeigt den Anschluß von zwei Laufwerken 
mit der Umsetzung vom 14poligen Atari-Disksteckerformat auf den 34poligen Shugart-Bus 
im Detail. 

Die ST-Computer sind vom Betriebssystem herdarauf ausgelegt, zwei Diskettenlaufwerke zu 
steuern. 

Die erste Diskstation (im Desktop das Laufwerk A) wird direkt am ST angeschlossen bzw. ist 
bereits eingebaut. Die zweite Station (Laufwerk B) wird an der “Out”-Buchse der ersten Disk¬ 
station, ebenfalls mit 14pol. Steckverbinder, angeschlossen. Beim ATARI 1040 STF, STE, 
TT und MEGA ST(E) ist für das zweite Laufwerk (externes Laufwerk) an der Rückseite des 
ST eine Buchse vorgesehen. 

Beim Betrieb von mehr als einem Laufwerk an einem FDC wird jedem Laufwerk eine eigene 
Identifikation zugeordnet. Dies geschieht auf der Laufwerksplatine durch entsprechendes 
Einstellen von DEP-Schaltem oder das Versetzen von Steckbrücken (Jumpern). Damit ist 
gewährleistet, daß sich Laufwerk A auch nur dann angesprochen fühlt, wenn es durch Low 
am “Drive select A”-Anschluß angesteuert wird. Laufwerk B darf nur reagieren, wenn es am 
“Drive select B "-Anschluß ein Low erhält, usw. 

Atari führt jedoch die “Drive select B”-Leitung vom Computer über die “In”-Buchse (An¬ 
schluß 6) auf den “Drive select A”- Anschluß (Anschluß 5) der “Out”-Buchse der Diskstation! 
Eine dort angeschlossene zweite Diskstation fühlt sich somit dann “auserwählt”, wenn “Drive 
select B” vom ST auf Low gesetzt wird. 

Das hat den Vorteil, daß keine Einstellarbeiten an der Diskstation nötig sind, weil alle Statio¬ 
nen als “Drive A” programmiert werden können (sie werden von ihrer “hC-Buchse über 



954 


ATARI Profibuch 



Laufwerksanschluß 





























Das Floppy-Disk-Interface 


955 


Dieses Prinzip hat jedoch auch den Nachteil, daß nur max. zwei Floppy-Stationen am ST 
betrieben werden können. 

Bei den Ataris mit eingebautem Laufwerk ist das interne Laufwerk immer als Drive A geschal¬ 
tet. An der Buchse für das externe Laufwerk ist der Anschluß für “Drive select B” (Anschluß 
6) über einen Pull-Up-Widerstand fest an +5V gelegt. Soll das Laufwerk B (externes Lauf¬ 
werk) selektiert werden, gibt der Computer an “Drive select A” (Anschluß 5) der Floppy- 
Buchse ein Low aus! Also muß das externe Laufwerk in diesem Fall auch hier wieder als 
“Drive A” eingestellt sein. 

Wie man trotzdem bei Ataris mit eingebautem Laufwerk das interne Laufwerk zu Drive B “de¬ 
gradiert” und das externe Laufwerk zum Drive A “ernennen” kann, ist ausführlich in einem 
Artikel im “ST-MAGAZIN/68000er”, Ausgabe 7/88, beschrieben. 

Fremd(körper)laufwerke am ST 

Mit Hilfe von zwölf Steuer- und Meldeleitungen steuert nun der ST die angeschlossenen 
Laufwerke. Die Hauptarbeit übernimmt dabei, wie schon vorher erwähnt, der Floppy-Disk- 
Controller. 

Die Steuerung der “Side select”- und “Drive select A bzw. B”-Leitungen erfolgt aber nicht 
durch den FDC, sondern wird vom Port A des Sound-Chip (PSG) vorgenommen. Das hat bei 
Anschluß von Fremdlaufwerken an den ST öfter zu Schwierigkeiten geführt, weil ein Port- 
Ausgang des PSG bei Low-Signal nur maximal 5 mA treiben kann. 

Die “Side select”- und “Drive select”-Eingänge an den normalen Laufwerken besitzen zwar 
in der Regel “Low-Power-Schottky”-Eingangsstufen, die mit geringen Steuerströmen (etwa 
1/4 des Standard-TTL Steuerstroms) auskommen, jedoch sind diese Eingänge meist über lkQ- 
Pull-Up Widerstände an +5V “gebunden”. Das schafft der Sound-Chip gerade noch so eben. 

Wird jedoch ein zweites Laufwerk angeschlossen, so sollte man bei einem der Laufwerke die 
Pull-Up-Widerstände für “Side select” und “Drive select” entfernen (sinnvollerweise beim 
ersten Drive in der Kette der Laufwerke, um den Leitungsabschluß am Ende der Kette zu 
haben)! Die Port-Ausgänge des PSG wären sonst überlastet; ein sicheres Steuern der 
Laufwerke ist nicht mehr gegeben. 

Man kann auch zur Erhöhung der Ausgangsleistung und zur Entlastung des Sound-Chips 
Treiberstufen (mit z. B. dem TTL-IC “7407”) für die “Side select”- und “Drive select A bzw. 
B”-Steuerleitungen Zwischenschalten. Dieses zusätzliche 14polige IC läßt sich noch relativ 
problemlos in einer Diskstation unterbringen und aus der Stromversorgung des Laufwerks 
speisen. Siehe hierzu den Schaltungsvorschlag in Abbildung 8.4. 
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Abb. 8.4: So kann man den Sound-Chip des ST bei der Laufwerksansteuerung wesentlich entlasten 


Viel Grips in kleinen Chips - Der FDC 

Im ST wird als FDC ein Chip desTyps WD1772eingesetzt. DieserTyp ist kompatibel zu FDCs 
der 179X-Serie, besitzt jedoch bereits einen eingebauten Datenseparator (um die Daten aus 
dem Strom von Daten- und Taktbits auszufiltem) und erlaubt eine höhere Steprate für die 
Kopfmotorsteuerung. 

Der “1772” kann Sektorgrößen von 128,256,512 oder 1024 Bytes/Sektor bearbeiten und das 
sowohl in einfacher als auch doppelter Dichte. Atari verwendet ein 512er Sektorenformat in 
doppelter Dichte. Das verwendete Format ist physikalisch kompatibel zum IBM-Diskformat. 
Schließt man ein 5,25 Zoll-Laufwerk an den ST an, so kann man im Prinzip und in der Praxis 
auf einem IBM- oder -kompatiblen PC formatierte und beschriebene Disks bearbeiten! 

Der FDC liefert an seinen Chip-Ausgängen für “Motor on”, “Step”, “Step direction” usw. die 
Steuerpegel genau entgegengesetzt, wie sie von den Diskstationen gebraucht werden. So geht 
z. B. bei der Funktion “Motor starten” der entsprechende Anschluß (MO = Motor on, Pin 20) 
des “1772” auf High-Pegel, während das Laufwerk den Motor bei Low-Pegel am “Motor on”- 
Anschluß startet. Deshalb sind im ST invertierende Treiberstufen (mit dem TTL-IC “7406”) 
zwischengeschaltet, die Ausgangsstufen mit offenen Kollektoren besitzen und so für die Pe¬ 
gelanpassung und den ebenfalls erforderlichen “Dampf’ auf den Steuerleitungen zu den Lauf¬ 
werken sorgen. 
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Der FDC im ST erhält Hilfe - von der DMA-Einheit 

Der FDC ist nicht direkt mit dem Daten- und Adreßbus des ST verbunden. Jeglicher Daten¬ 
austausch läuft nur “unter Aufsicht” der DMA-Einheit (siehe Abbildung 8.5). 
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Über die A0-, Al- und CS-Leitung selektiert der DMA-Baustein die Register des FDC. Der 
logische Zustand der R/W-Leitung informiert den FDC darüber, ob ein Schreib- oder Lese¬ 
zugriff auf eines seiner Register erfolgt. 

Per (High-)Signalisierung auf der DRQ-Leitung bekommt die DMA-Einheit mitgeteilt, wann 
ein “Data request” (Datenanforderung) des FDC vorliegt. Hierüber teilt der FDC mit, daß er 
Daten von der DMA-Einheit erwartet bzw. Daten bereitgestellt hat (beim Lesevorgang), die 
von der DMA-Einheit abgeholt werden müssen. Das Ende einer Operation meldet der FDC 
mit einem High auf der INTRQ-Leitung an den Port 15 des MFP (über das NOR-Gatter wird 
dieses High dann zu einem Low am MFP-Port 15). 

Der Anschluß DDEN (Double Density ENable = Doppelte Schreibdichte anwählen, Pin 26 
des FDC) ist im ST fest auf Low gebunden. Damit kann der FDC nur mit dem MFM-Aufzeich¬ 
nungsverfahren (MFM = Modified Frequency Modulation) betrieben werden. Aber es wird 
ja in modernen Mikrocomputersystemen (und dazu kann man die ST-Serie ja wohl zählen) 
ausschließlich in doppelter Dichte gearbeitet. 

Inzwischen nutzt man ein nicht dokumentiertes Feature des FDC’s vom Typ WD1772 aus. So 
vertragen einige Chips dieses Typs eine Verdoppelung der Taktrate an ihrem Clk-Eingang, 
Wenn statt mit dem Standard-8-MHz-Takt mit 16 MHz gearbeitet wird, geht alles doppelt so 
schnell, und der FDC hat auf einmal High-Density. Auf diese Weise verfahrt Atari beim TT 
und Mega STE, um die internen Drives mit High-Density fahren zu können. Nur verwendet 
man nicht den Original WD1772-Chip dafür, sondern einen eigenen Chip, der auch laut Spezi¬ 
fikation die Verdoppelung der Taktrate mitmacht! 


Die Register des FDC 

Wie das Übersichtsbild in Abbildung 8.5 ebenfalls zeigt, besitzt der FDC fünf Register zu je 
8 Bit Breite. Je nach auszuführender Operation ist es zunächst erforderlich, einige dieser 
Register mit den erforderlichen Voreinstellungen zu versehen, bevor in das Kommandoregister 
das Kommandobyte eingeschrieben wird. 

Das Track-Register (AO=l, AI=0, RAV) enthält die Nummer der Spur, über der sich der Kopf 
gegenwärtig befindet. Eine Schreib-/Lese- oder Verify-Operation kann nur erfolgen, wenn der 
Inhalt des Track-Registers mit der im ID-Feld auf der Disk enthaltenen Spurnummer 
übereinstimmt. Das Register kann gelesen und beschrieben werden. Während der FDC eine 
Operation ausführt, sollte kein Zugriff auf das Register durchgeführt werden. 


Der FDC besitzt nur ein Trackregister, der ST aber bis zu zwei Laufwerke. Dummerweise 
befinden sich die Köpfe der beiden Laufwerke selten über der gleichen Spur. Deshalb muß 
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bei einem Laufwerkswechsel die aktuelle Spumummer des Laufwerks, mit dem momentan 
nicht gearbeitet wird, zwischengespeichert werden. 

Dies geschieht beim ST im sogenannten Drive Status Block (DSB). Und da maximal zwei 
Disklaufwerke angeschlossen sein können, gibt es logischerweise zwei DSBs! Das erste 
Datenwort des jeweiligen DSB enthält die Spumummer, über der sich der Kopf gerade befin¬ 
den sollte. Im zweiten Wort findet sich die Steprate, mit der das Laufwerk seinen Schreib-/ 
Lesekopf Uber die Disk hetzt. Je nach TOS-Version ergeben sich für die Anfangsadresse der 
beiden DSB andere Werte. 

Hier die Adressen für einige TOS-Versionen: 



[ RAM-TOS 

RAM-/ROM-TOS 

Blitter-TOS 

1 Rainbow- 


11/1985 

vom 6.2.86 

vom 22.4.87 

1 TOS 1.04 

DSB Drive A 
Acurtrack 

1 

$6C8 

$A06 

$A4C 

$A4C 

Aseekrt 

$6CA 

$A08 

$A4E ' 

$A4E 

DSB Drive B 
Bcurtrack 

$6CC 

$A0A 

: 

$A50 

$A50 

Bseekrt 

$6CE ' 

$A0C 

$A52 

$A52 


Man sollte jedoch diese Variablen nicht unbedingt verwenden! Da aber zumindest die 
Einstellung der Seekrate bei Anschluß von 5,25-Zoll-Laufwerken sehr wichtig ist, hat ATARI 
in den “Rainbow TOS Release Notes” dann für das ROM-TOS 1.00 und Version 1.02 
(“BLUTER-TOS”) die Lage der Adressen für “Aseekrt” und “Bseekrt” dokumentiert. Auf 
andere Art und Weise ist keine getrennte Einstellung der Steprate für die Laufwerke möglich. 
In TOS-Versionen 1.04 und höher ist die Steprate über den XBIOS-Aufruf #41, “FloprateO”, 
konfigurierbar. 

Im Sector-Register (A0=0, Al-1, R/W) wird dem FDC die Nummer des anzusteuemden 
Sektors mitgeteilt. Ein Schreib- oder Lesezugriff erfolgt nur bei Übereinstimmung mit der 
Sektomummer im ID-Feld des Sektors auf der Disk. Das Sector-Register kann beschrieben 
und gelesen werden. Auch für dieses Register gilt: Nicht ansprechen, solange eine Operation 
nicht beendet ist. 

Das Data-Register (A0= 1, A1=1, R/W) wird benutzt, um dem FDC die zu schreibenden Daten 
Byte für Byte zu übermitteln. Während einer Leseoperation stehen hier die gelesenen Bytes 
für den Prozessor (beim ST macht das die DMA-Einheit) zum Abholen bereit. Bei einem 
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“SEEK”-Kommando (Gezieltes Ansteuem einer Spur) wird dem FDC im Data-Register die 
gewünschte Spur mitgeteilt, die “angefahren” werden soll! 

Durch Einschreiben eines Bytes in das Command-Register (A0=0, A1 =0, Write only) wird der 
FDC aufgefordert, eine bestimmte Operation auszuführen. Das Register kann nur beschl ieben 
werden. Während einer laufenden Operation darf das Register nicht neu beschrieben werden, 
es sei denn, die laufende Aktion soll unterbrochen werden. 

Aus dem Status-Register (A0=0, A1=0, Read only) kann eine Zustandsinformation über das 
durchgeführte Kommando abgerufen werden. Die Bedeutung der einzelnen Statusbits hängt 
von dem ausgeführten Kommando ab. Da es sich um ein Zustandsregister handelt, ist nur ein 
Auslesen möglich und sinnvoll. Es darf auch während einer laufenden Operation ausgelesen 
werden! 


Die Kommandos des ST-Floppy-Controllers 

Der FDC kennt insgesamt elf verschiedene Kommandos, die in vier verschiedene Kategorien 
(Typen) eingeteilt sind. Sie sind in der Abbildung 8.7 aufgeführt. 

Die Kommandos werden ins Command-Register geschrieben und unmittelbar nach Beendi¬ 
gung des Einschreibvorgangs ausgeführt. Das Laden des Command-Registers sollte nur bei 
gelöschtem BUSY-Bit des FDC-Status-Registers durchgeführt werden, da sonst die laufende 
Operation unterbrochen wird! 

Eine Ausnahme bildet hierbei das “Force Interrupt”-Kommando, das jederzeit gesendet wer¬ 
den kann, aber - wie der Name eben schon ausdrückt - sowieso nur zur Unterbrechung von 
einer gerade laufenden Operation benutzt wird. 

Solange ein Kommando bearbeitet wird, ist das BUSY-Bit im Status-Register gesetzt. Bei 
Operationsende wird es gelöscht und ein Interrupt ausgelöst, der über die IRQ-Leitung zum 
Port 15 des MFP geleitet wird. 

Der Inhalt des Status-Registers gibt dann Aufschluß darüber, ob die Operation korrekt durch¬ 
geführt wurde bzw. welche Fehler aufgetreten sind. 

Es läßt sich auf zwei Arten feststellen, ob der FDC ein Kommando abgeschlossen hat. 

- BUSY-Bit (Bit 0) im Status-Register so lange testen, bis es vom FDC zurückgesetzt wird. 

Bevor jedoch nach dem Absenden des Kommandos an den FDC (Einschreiben in das 
Command-Register) zum ersten Mal das Status-Register abgefragt wird, sollte man dem 
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FDC eine Pause von mindestens 32 ps gönnen. Eher sind die Bits im Status-Register nach 
Start eines Kommandos nämlich noch nicht gültig! 

Warten!!! Nicht ewig, sondern bis der FDC einen Interrupt auslöst. Dazu wird der An¬ 
schluß INTR (Pin 28 des FDC) auf High gesetzt. Als Folge davon wird dann im ST beim 
Port 15 des MFP ein Low auftreten. 


Also nach Start eines FDC-Kommandos immer mal bei Port 15 des MFP nachschauen, 
ob schon ein Low anliegt, der FDC ist dann nämlich fertig. Das ist auch die vom Betriebs¬ 
system des ST praktizierte Methode. 


Bit—Nr. 

Bedeutung 

7 

Zustand des 'Motor on'-Anschlusses C'l* ~ Motor on) 

6 

Bei READ SECTOR und READ TRACK ohne Funktion. Bei jeden 
WRITE-Befehl wird hiernit ein Schreibschutz angezoigt. 

5 

Typ l-Konnandos: Gesetzt sobald flotor-'Spin up 1 erfolgt ist. 

CG Indexpulse nach 'Motor on 1 ) 

Typ 11..11I —Konnandös: *1'= Sektor nit * De 1e ted 1 -Data nark. 

* 0'— Sektor nit 'Ualid'-Data nark. 

4 

Gesetztes Bit zeigt an, daß gewünschter Sektor, Spur oder 
Seite nicht gefunden wurde. iRetora not found) 

3 

Gesetzt wenn CRC-Error festgestellt wurde. 

2 

Typ I-Kormandos: Zustand des 'Track BÖ 1 -Anschluß. 

C'l' = Kopf über Spur 0BJ 

Typ II.,II1-Konnandos: Wird '1* wenn die CPU (DMA! bein Da¬ 
tentransfer zu langsan reagiert hat. 
C'Lost Data *-Bit■J 

1 

Typ I-Konnandos ’ Zustand des Index-Anschluß 

Typ I1..III-Konnandos: Zustand des DftQ-Anschluß. 

Ci" = Data Register nuß 'bedient' 
werden.J 

0 

■BUSV'-Bit, Ein Konnando ist in Bearbeitung. 


Abb. 8.6: Die Bedeutung der Bits im FDC-Status-Register 


Kommandos des Typs I 

Hierunter sind alle Kommandos zusammengefaßt, die zur Kopfpositionierung benutzt 
werden, wie RESTORE, SEEK, STEP, STEP-IN und STEP-OUT. 

Hier wird gesteppt! 

Alle fünf Kommandobytes des Typs Ibeinhalten in ihrem Befehlsbyte ein Feld von 2 Bits, die 
zur Einstellung der Spurwechselzeit (Steprate) dienen. Folgende Stepraten sind möglich: 
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ri j 

[ r0 

Steprate 

0 

0 

6 ms 

(bei 40-Spur-Drives (5,25") üblich) 

o 1 

1 

12 ms 


1 

0 

2 ms 

(bei manchen 3,5"-Floppies möglich) 

i ! 

1 

3 ms 

(bei 80-Spur-Drives (3,5" und 5,25") gängig) 


Mit jedem Step-Impuls wird der Kopf um eine Spur weiterbewegt. Die Richtung wird dabei 
durch den Zustand am “Step direction”-Anschluß signalisiert. Der Pegel am “Step direction”- 
Anschiuß bleibt so lange gleich, bis der Kopf durch ein entsprechendes Kommando in die ent¬ 
gegengesetzte Richtung bewegt werden soll! 

Nach Ausführung des letzten Steps in die gewünschte Richtung wird dem Kopf eine “Beruhi¬ 
gungspause” von 30 ms gegönnt, um evtl. Vibrationen in der Kopfpositioniermechanik abklin- 
gen zu lassen. Dies geschieht jedoch nur bei gesetztem “V-Bit” (Verify-Bit) oder gesetztem 
“E-Bit” der Kommandos des Typs II + DI. 

Überprüfung ist wichtig 

Ist also das “V-Bit” gesetzt, so erfolgt nach der Kopfberuhigungszeit eine Überprüfung, ob 
der Kopf sich denn nun wirklich über der gewünschten Spur befindet. 

Dazu wird die Tracknummer aus dem ersten vorbeikommenden ID-Feld gelesen und mit der 
Spumummer im Track-Register verglichen. Stimmen diese überein und ist die CRC-Prüfsum- 
me des gelesenen ID-Feldes korrekt, ist die Verify-Prozedur beendet. Der FDC erzeugt dann 
einen Interrupt als Zeichen der Beendigung des Kommandos und signalisiert im Status-Regi¬ 
ster den Erfolg der Operation. 

Stimmt beim Verify zwar der Track, ergibt die CRC-Überprüfung aber einen Fehler, so gibt 
der FDC nicht gleich auf, sondern wiederholt die gleiche Überprüfungsprozedur mit dem 
nächsten ID-Feld. 

Findet der FDC bei dieser Verify-Prozedur innerhalb von fünf Diskumdrehungen keine 
Übereinstimmung zwischen Track-Register und Spumummer in den ID-Feldem, so wird die 
Operation mit einem Interrupt beendet und das “Seek Error-Bit” im Status-Register gesetzt. 

Auszeit für den Laufwerksmotor 

Ist bei den Kommandos des Typs I..III das “h”-Bit gelöscht (“Motor on”-Flag), so wird die 
eigentliche Operation erst gestartet, wenn der FDC der Ansicht ist, daß der Antriebsmotor des 
Laufwerks mit Solldrehzahl läuft! 
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Befehl 


RESTORE 


SEEK 


STEP 


STEP-IN 


READ SECTOR 


MRXTE SECTOR 


READ ADDRESS 


READ TRACK 


MRITE TRACK 


FORCE 1HTERRUPT 


für' Ktmnandvs des Typs I 
h - 'Motor on'-FIag 


Konnandobyte 


u 

rl 

rO 

u 

rl 

re 

u 

rl 

r0 




u = 'Update'-Flag 



0 = 'Uerifg*-Flag 


V = O : Kein Veri-Fy 
M = 1 I Test «uf Korrekte Spur 


u Ä 0 

u a 1 

Kein 'Update* 
ftktualis., des Tr-acK Reg- 



rl, r0 

= Stepinpuls-fiate I 


für- Konnandos des Typs II * III 

n = ‘Mult:- Sector'-Flag 1 [e - 'Head settling * -Flag 1 


iv» s O 5 •'Single- sec tor J -Zugri ■F-F 
m = 1 2 'Multiple sector'-Zugrift 


Keine Verzögerung 
30ws Verzögerung 


a0= 'Data addr . nark'-Bit 


ü0= 0 : Schreibe ■»Nortt-ale-' DRM 
a0= 1 : Schreibe 'Deieted' drm 


= ’Urite Prekonpensat. 


'RreKenpensütion' Ein 
'PpcHowpcnSÄtion' Aus 


für- Typ lU-KoMiandos 

~FORCE 1HTERRUPT■-Bedingungsbits 


Nicht zulässig 
Rieht zulässig 

Interrupt bein nächsten Indexpuls 
Sofortige Unterbrechung der Operation 
= B s Operation ohne Interrupt abbrechen 


Abh. 8.7: Die Kommandos des Floppy-Controllers WD 1772 
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Gönnt der FDC über den “Motor on”-Anschluß (Pin 20 des FDC) dem Laufwerksmotor gerade 
eine Pause, so wird ein Kommando mit gelöschtem "h”-Bit zuerst den Drive-Motor über die 
“Motor on”-Leitung starten und dann fünf Umdrehungen warten (Die Umdrehungen werden 
mittels der Indexpulse gezählt). 

Nach diesen fünf Umdrehungen (ca. 1 s bei 300 U/min) geht der FDC davon aus, daß der Lauf¬ 
werksmotor seine Nenndrehzahl erreicht hat, und fährt mit der Operation fort. 

Nach Beendigung derOperation wartet der FDC noch zehn Diskrotationen (wieder Indeximpulse 
zählen!), bis der Motor gestoppt wird. Damit wird verhindert, daß der Motor evtl, ständig läuft 
und der Kopf einen “Graben” in die Diskette “pflügt”. 

Wird einKommando mitgelöschtem “h”-Bit gegeben und läuft der Motor noch auf Nenndreh¬ 
zahl (“Motor on”-Bit im Status Register noch gesetzt), so entfällt natürlich die Hochlaufzeit 
für den Laufwerksmotor von 1 s. Das hört sich in der Theorie ganz simpel an, in der Praxis treten 
jedoch hin und wieder Probleme auf. 

So funktioniert die ganze Zählerei mit den Indeximpulsen natürlich nur dann, wenn das Lauf¬ 
werk auch selektiert ist. Die Diskstation ständig selektiert zu lassen ist aber auch nicht die 
ideale Lösung. Vor allem dann nicht, wenn mit mehr als einem Laufwerk gearbeitet wird. 
Dannlaufen jaauf der Indeximpuls-Leitung die Indeximpulse allerangeschlossenen Laufwerke 
gleichzeitig beim FDC auf! Das TOS versucht das Problem folgendermaßen zu lösen: 

In jedem Vertikal-Blank-Interrupt wird überprüft, ob der FDC inzwischen den Laufwerksmotor 
per “Motor ori'-Leitung abgeschaltet hat. Ist das der Fall, wird das Laufwerk deselektiert! 

Das führt jedoch zum nächsten Problem. Die VBlank-Interrupt-Routine zur Überprüfung der 
“Motor on”-Leitung muß ja dazu auf das Status-Register des FDC zugreifen (Bit 7 des Status- 
Registers zeigt ja den Zustand der “Motor on”-Leitung an) und “stolpert” einer evtl, gerade 
laufenden Diskoperation dazwischen. 

Also hat ATARI in seinen Betriebssystemvariablen ein Flag eingerichtet (“flock” = Floppy- 
Disk-lock (Floppy-Verriegelung) an Adr. $43E), das immer dann gesetzt ist (auf oO), wenn 
gerade eine Diskoperation stattfindet. Die Interrupt-Routine im V-Blank schaut immer zuerst 
bei “flock” nach, ob ein Zugriff auf den Disk-Controller zulässig ist. Bei gelöschtem Flag 
(flock=0) darf die V-Blank-Interrupt-Routine auf die Register des FDC zugreifen. 

Wenn keine Disk eingelegt ist, weil z. B. von Harddisk gebootet wurde, kann das Deselektieren 
aber gar nicht klappen, weil (mangels Disk) keine Indeximpulse gezählt werden können. Da¬ 
mit schaltet der FDC den Laufwerksmotor aber auch nicht ab, und als Folge davon kann die 
VBlank-Routine auch das Laufwerk nicht deselektieren! 



Das Floppy-Disk-Interface 


965 


RESTORE - Zurück an den Anfang 

Einer der wichtigsten Positionierungsbefehle ist das Kommando RESTORE. Es sorgt dafür, 
daß der Kopf so lange schrittweise in Richtung “Heimat” (Home-Position = Spur 00) bewegt 
wird, bis über die “Track 00”~Leitung (Pin 23 des FDC) eine Signalisierung (Low-Pegel) er¬ 
folgt. Das bedeutet dann nichts anderes, als daß der Kopf nun Spur 00 erreicht hat. 

Ist das der Fall, so wird das Track-Register auf $00 gesetzt und ein Interrupt ausgelöst. Sollte 
jedoch nach 255 Step-Impulsen immer noch keine “Track 00”-Signalisierung erfolgt sein, so 
wird die Operation “interrupted” und im Status-Register das “Record not found”-Bit gesetzt 
(nur wenn mit “Verify” gearbeitet wird!). 

Benutzt wird der RESTORE-Befehl immer vor einem Zugriff auf die Disk, wenn nicht genau 
bekannt ist, über welcher Spur sich der Kopf befindet (z. B. nach dem Einschalten des Sy¬ 
stems). Die “V”-,”h”-,”rlund “r0”-Bits wirken auch hier wie bereits beschrieben. 

Wer suchet, der Endet - Der SEEK-Befehl 

Die SEEK-Operation (Suchen) erlaubt das gezielte Anfahren einer Spur. 

Der FDC erwartet dabei im Data-Register (!) die Nummer der Spur, über die der Kopf positio¬ 
niert werden soll, während sich im Track-Register die Spumummer der augenblicklichen 
Kopfposition befindet. Es werden dann vom FDC so lange Step-Impulse in der nötigen Rich¬ 
tung ausgegeben, bis der Inhalt des Track-Registers (welches jeden Step mitzählt) mit der ge¬ 
wünschten Spumummer im Data-Register übereinstimmt. 

Ein “Verify” über der gewünschten Spur ist natürlich auch hier möglich durch Setzen des V- 
Bits. Nach Abschluß der Operation wird wieder ein Interrupt erzeugt und die Status-Bits im 
Status-Register entsprechend gesetzt. 

Mehr Speed durch weniger Kontrolle - SEEK ohne Verify 

Dieses gesetzte Verify-Bit sorgt im TOS dafür, das die Diskzugriffe nicht mit der eigentlich 
möglichen Geschwindigkeit ablaufen. So wird nämlich bei jedem (!) Disk-Zugriff des TOS, 
der ein SEEK erfordert (und das sind die meisten!), eine SEEK-Routine aufgerufen, die für 
die Positionierung des Kopfs sorgt. Bei “SEEK mit Verify” wird über der gewünschten Spur 
noch zur Kontrolle ein ID-Feld eingelesen und die darin enthaltene Spumummer mit der ge¬ 
wünschten Tracknummer verglichen. 

Das kostet Zeit, die man sich eigentlich sparen kann, weil die Positionierung zum einen wenig 
fehleranfällig ist und außerdem beim normalerweise anschließend folgenden Zugriff auf 
Sektoren der angesteuerten Spur ja sowieso eine Überprüfung auf die korrekte Adresse (Sektor 
und Spur!) erfolgt. 
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Durch Rücksetzen des Verify-Bits in dieser SEEK-Routine des TOS kann man Diskzugriffe 
um bis zu 50% beschleunigen! Bei TOS im RAM läßt sich das Bit problemlos ändern (beim 
RAM-TOS von 11/85 ist die Speicherstelle $68C3 von $14 auf $10 zu ändern. Im RAM-TOS 
vom 06.02.87 ist die interessante Speicherstelle bei $7A1D). 

Für TOS im ROM existieren Hilfsprogramme, die sich beim Start des Systems ins TOS ein¬ 
klinken und den Ansprung der ROM-SEEK-Routine in eine modifizierte SEEK-Routine im 
RAM umleiten, welche dann ohne Verify arbeitet. 

Es gibt auch sogenannte FASTLOAD-EPROMS, die anstelle der Original-ROMs eingesetzt 
werden und bei denen das Verify-Bit nicht gesetzt ist. Im TOS 1.00 ist das die Speicherstelle 
$0DC7, im TOS 1.02an Adresse $0EC7 und im TOS 1.04 bei $ 1517. Die Adreßangaben gelten 
jeweils für ROM U7 (ST), ROM U67 (STF) bzw. ROM U10 (MEGA ST). 

STEP IN, STEP OUT - Schritt für Schritt über die Diskette 

Mit jedem STEP-Kommando gibt der FDC einen Step-Impuls aus. Die Bewegungsrichtung 
(“Step direction”) ist dabei die gleiche wie bei dem zuletzt ausgeführten Schritt. Ist das 
“Verify”-Bit gesetzt, erfolgt nach Ablauf derZeitfür dieSteprate (rl-, TO-Bits im Kommandobyte) 
und Kopfberuhigung eine Überprüfung, ob der Kopf auf dem richtigen Track gelandet ist. 

Bei den STEP-Kommandos existiert im Kommandobyte noch das sogenannte “Update”-Bit 
(“U”-Bit). Ist es gesetzt, wird das Track-Register je nach Steprichtung um 1 erhöht oder ernie¬ 
drigt. Das Track-Register ist somit also immer up(to)date. 

Um aber den Kopf nicht immer nur in eine Richtung bewegen zu können (STEP ändert ja nicht 
die Bewegungsrichtung), gibt es noch die STEP-1N- und STEP-OUT-Befehie.Wie der Name 
schon sagt, wird hier der Kopf einen Schritt nach innen (zur Diskettenmitte) oder nach außen 
(in Richtung Track 00) bewegt. “Update” und “Verify” arbeiten auch hier wie schon zuvor 
erläutert. 

Nach Abschluß eines der Step-Kommandos wird wieder ein Interrupt ausgelöst. Der Status 
der Operation kann natürlich wieder aus dem Status-Register ausgelesen werden. 


Kommandos des Typs II - Jetzt geht’s an die Daten 

Die FDC-Kommandos des Typs II dienen dem sektorweisen Datenzugriff auf die Disk. 

Bevor ein READ- oder WRITE SECTOR-Kommando ausgeführt werden soll, muß das 
Sector-Register mit der Nummer des zu bearbeitenden Sektors geladen werden. Erst dann wird 
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das READ- oder WRITE SECTOR-Kommando gegeben. Wie schon bei den Typ I- 
Kommandos wird auch hier durch ein gesetztes “BUSY”-Bit im Status-Register signalisiert, 
daß der FDC fleißig ist. Ist auch noch das “E”-Bit gesetzt, wird der FDC mit dem Beginn des 
Datenzugriffs warten, bis die Kopfberuhigungszeit von 30 ms abgelaufen ist. Aber dann... geht 
erst mal die Sucherei los! 

Der FDC versucht zunächst, ein ID-Feld auf der Spur zu finden. Die Spur- und Sektomummer 
des ID-Feldes muß natürlich mit den Daten im Track- und Sector-Register übereinstimmen. 

Wenn dann auch noch die CRC-Priifsumme über das ID-Feld stimmt, kann endlich der dem 
ID-Feld folgende Datensektor gelesen oder beschrieben werden. Für die Suche nach einem 
passenden ID-Feld hat der FDC fünf Diskumdrehungen Zeit, sonst gibt es einen Interrupt mit 
gesetztem “Record not found”-Bit im Status-Register. 

Neben dem schon bekannten “Motor on”-Flag gibt es bei diesem Kommando-Typ noch ein 
“m”-Bit (“READ/WRITE Multiple sectors"): 

- Bei gelöschtem “m”-Bit wird nur ein Sektor gelesen oder geschrieben. 

Bei gesetztem “m”-Bit werden alle Sektoren ab der Sektomummer im Sector-Register 
so lange gelesen oder beschrieben, bis der FDC z. B. per “Force interrupt”-Kommando 
unterbrochen wird oder ein Fehler auftritt. Das Sector-Register wird dabei kontinuierlich 
mit jedem gelesenen/geschriebenen Sektor heraufgezählt (“Auto updating”), bis die 
Sektomummer im Sector-Register größer als die größte Sektomummer in der Spur ist. 

Beim ST würde der FDC also bei einer “READ MULTIPLE SECTORS”-Operation, begin¬ 
nend mit dem Sektor 5, dann abgebrochen, wenn die Sektoren 5..9 gelesen wurden und der 
FDC vergeblich nach einem Sektor 10 Ausschau hielte (Sektomummer 1..9 sind ja normal). 

Immerhin blieben dem FDC jedoch fünf Diskumdrehungen Zeit, den Sektor 10 vielleicht doch 
noch zu finden. Erst dann würde die Operation mit gesetztem “Record not found”-Bit im 
Status-Register abgebrochen. Um sich diese Wartezeit zu sparen, wird man den FDC mit 
“Force intemipt” dann unterbrechen, wenn genug Daten geschrieben oder gelesen wurden. 

READ SEKTOR 

Folgendes spielt sich ab, nachdem der FDC ein READ SECTOR-Kommando empfangen hat: 

Der FDC schaltet auf BUS Y. (“BUS Y”-Bit im Status Register setzen). Evtl, wird gewar¬ 
tet, bis der Motor mit Solldrehzahl läuft (“h”-Bit) und sich der Kopf wieder beruhigt hat 
(“E”-Bit). 
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Ein passendes ID-Feld (Track, Sektor, CRC-Bytes) wird gesucht. Ist es gefunden, muß 
in einem der folgenden 43 Bytes eine “Data-address-mark” (DAM) gefunden werden. 
Für diese Sucherei hat der FDC fünf Umdrehungen Zeit (sonst erfolgt ein Interrupt mit 
gesetztem “Record not found”-Bit im Status-Register). 

Nach der gefundenen DAM werden Datenbytes eingelesen. Das erste Byte der Daten 
gelangt ins Data-Register. Der FDC signalisiert durch High am DRQ-Ausgang (Data 
Request = Pin 27 des FDC) und durch Setzen des “DRQ’VBits im Status-Register, daß 
ein Datenbyte abgeholt werden muß. 

- Sollte das Data-Register nicht rechtzeitig vor dem Eintreffen des nächsten Datenbytes 
ausgelesen worden sein, wird das vorhergehende Byte im Data-Register mit dem von 
Disk neu gelesenen Byte überschrieben. Im Status-Register wird dann das “Lost data”- 
Bit gesetzt. 

Es werden alle Datenbytes des Sektors nacheinander eingelesen. Sollte zu allem Übel 
auch noch die CRC-Prüfung einen Fehler ergeben, so wird das “CRC error”-Bit gesetzt 
und die Operation unterbrochen (auch wenn es sich um ein “READ MULTIPLE SEC- 
TORS”-Kommando handelt). 

Nach Abschluß der Leseoperation wird durch das “Sector type”-Bit im Status-Register 
signalisiert, ob die gelesenen Daten als gültig oder gelöscht zu deuten sind .Gültige Daten 
werden durch eine “Data address mark” = $FB vor den Sektordaten gemeldet. Das 
“Sector type”-Bit im Status-Register ist dann gelöscht. Ein Sektor mit als “gelöscht" 
geltenden Daten wird durch ein gesetztes “Sector type”-Bit angezeigt (“Data address 
mark”=$F8). Beim ST wird nur mit “gültigen” Sektoren gearbeitet, weil das TOS sich 
selbst merken kann, welche Sektoren frei und welche mit gültigen Daten belegt sind. 

Soviel zum Kommando READ SECTOR. 

Wie die Pfiffigen unter den Lesern jetzt wahrscheinlich schon messerscharf geschlossen 

haben, geht es nun weiter mit dem Kommmando 

WRITE SECTOR 

Bei diesem Kommando läuft folgender Vorgang ab: 

- “BUS Y”-Bit-Setzen, “Motor on”-Flag und evtl. Kopfberuhigung abwarten funktioniert 
genauso wie bei READ SECTOR. 

- Die “Write protect”-Leitung wird abgefragt. Wenn die Disk im angesprochenen Lauf¬ 
werk schreibgeschützt ist, geht’s gar nicht erst weiter. Dann wird nämlich “interrupted” 
und im Status-Register zur Information das “Write protecf’-Bit gesetzt. 
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- Wenn der Schreibzugriff erlaubt ist, erfolgt genau wie bei READ SECTOR die Suche 
nach einem Sektor mit passendem ID-Feld. Hat der FDC ein passendes ID-Feld mit 
korrekter CRC-Prüfsumme gefunden, wird nach zwei weiteren Lückenbytes der DRQ- 
Anschluß aktiviert und das “DRQ”-Bit im Status-Rgister gesetzt. Das erste zu schreiben¬ 
de Datenbyte muß innerhalb der nächsten neun Lückenbytes ins Data-Register geladen 
werden, sonst wird mit gesetztem “Lost Data”-Bit unterbrochen, 

22 Bytes nach dem letzten CRC-By te des ID-Felds (bei MFM) wird der FDC den “ Write 
gate”-An$chluß aktivieren und zwölf Bytes mit $00 schreiben. Dann folgt die “Data- 
address-roark” (DAM=$FB bei “a0”-Bit=0, DAM=$F8 bei “aO”-Bit=l). 

- Nun erst folgen die eigentlichen Datenbytes, welche von der CPU rechtzeitig ins Data- 
Register transportiert werden müssen. Die Signalisierung, wann wieder ein Byte fällig 
ist, geschieht über den DRQ-Anschluß (Pin 27 des FDC) und das “DRQ”-Bit im FDC- 
Status-Register. Gerät die CPU (im ST macht das der DMA-Baustein) bei der Daten¬ 
bereitstellung “aus dem Tritt”, wird für jedes fehlende Byte ein $00-Byte geschrieben. 
Dieser Fehler wird dann mit gesetztem “Lost Data”-Bit im Status-Register angezeigt. 

- Nach dem letzten Byte des Datenfeldes eines Sektors wird die CRC-Prüfsumme ge¬ 
schrieben. Dann kommt noch ein Byte mit $FF (wer weiß wofür?), und anschließend er¬ 
folgt der Interrupt, der das Ende der Operation anzeigt. 

Damit ist ein Sektor geschrieben. Beim WRITE SECTOR-Kommando kann das sogenannte 
Prekompensations-Bit (“P"-Bit) verwendet werden. Bei gelöschtem “P”-Bit erhöht sich damit 
die Datensicherheit auf den inneren Spuren, auf denen die Bits (und damit die kleinen 
“Stabmagnete”) wesentlich näher beieinanderliegen als auf den äußeren Spuren. 

Um “Bitwanderungen” durch zwei zu nah nebeneinanderliegende “Stabmagnete” von vorn¬ 
herein zu erschweren (nebeneinanderliegende gleiche Magnetpole stoßen sich ja bekanntlich 
ab, während sich ein ungleiche Pole gar nicht nah genug kommen können!), werden gleiche 
Pole etwas näher beieinander geschrieben (sie werden sich schon von allein voneinander ent¬ 
fernen). Ungleiche Pole werden etwas weiter voneinander entfernt aufgezeichnet, weil sie ja 
doch das Bestreben haben, sich einander zu nähern. 

Beim ST arbeitet ATARI immer mit gelöschtem “P”-Bit, egal auf welche Spur zugegriffen 
wird. Die Schreibvorkompensation ist also immer eingeschaltet! 

Diagnose- und Formatierkommandos - Typ ÜI-Befehle 

Mit den Kommandos des Typs III hat man die Möglichkeit, mehr Informationen von der Dis¬ 
kette zu holen bzw. darauf zu schreiben als mit den Sektorzugriffen der Typ Ü-Kommandos. 
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Adresse gesucht! - READ ADDRESS 

Das Kommando READ ADDRESS ermöglicht es, nur das nächste “vorbeikommende” ID- 
Feld eines Sektors (eben seine Adresse auf der Disk) auf einer Spur einzulesen. Dies ist nur 
6 Bytes lang (Spur-, Seiten-, Sektomummer, Sektorlängenkennung und die zwei CRC-By tes). 
Auch bei READ ADDRESS besteht natürlich wieder die Möglichkeit, mit dem “Motor on”- 
Flag (“h”-Bit) und einer Kopfberuhigungszeit (“E”-Bit) zu arbeiten. 

Nach Empfang des Kommandos setzt der FDC wie gehabt das “BUSY”-Status-Bit und wird 
dann das nächste ID-Feld Byte für Byte an das Data-Register übermitteln. Von dort müssen 
diese Bytes nach und nach, entsprechend der Signalisierung mit der DRQ-Leitung bzw. dem 
DRQ-Status Bit, abgeholt werden (bei verspätetem Auslesen wird wieder “Lost Data” signa¬ 
lisiert!). 

Die Gültigkeit der gelesenen Bytes wird natürlich per CRC-Checksumme überprüft und ent¬ 
sprechend im Status-Register angezeigt (Bit 3 = “CRC Error”-Bit). Zusätzlich wird die gelese¬ 
ne Tracknummer des ID-Felds ins Sector-Register (!) kopiert und steht dort für evtl. Verglei¬ 
che zur Verfügung. Das Ende der READ ADDRESS-Operation wird auch wieder ganz normal 
über Interrupt und Reset des “BUSY”-Bits angezeigt. 

WRITE TRACK 

ist der eigentlich wichtigste Befehl überhaupt, über den der Floppy-Controller verfügt. Nur 
mit diesem Befehl ist es nämlich möglich, alle erforderlichen Informationen auf die Disk zu 
bekommen. 

Mit WRITE TRACK wird eine Diskette formatiert! 

Dazu legt man sich in einem Speicherbereich des Computers Byte für Byte ein “Doppel” der 
zu formatierenden Spur an. Dieser “Memory Track” enthält, einschließlich Markierungs- und 
Synchronisationsbytes, alle Informationen für den zu schreibenden Track. Und diese Spur 
sieht dann folgendermaßen aus (zur besseren Übersicht ein Auge auf Abbildung 8.8 halten): 

Da wären also zunächst 60 Bytes mit $4E, dann zwölfmal die $00, dreimal die $ AI mit fehlen¬ 
den Taktflanken zur Identifizierung des ersten ID-Feldes, dann die ID-Address-Mark ($FE) 
selbst,... Moment mal, wie war das gerade mit den fehlenden Taktflanken? Wo kommen die 
denn her, bzw. wie läßt man die denn weg? 

Fehlende Flanken sind auffällig - Markierungen auf der Disk 

Um solche Marken mit fehlenden Taktflanken zu schreiben, gibt es beim WRITE TRACK- 
Befehl des FDC bestimmte Bytes, die der FDC nicht als “normale” zu schreibende Bytes 
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ansieht, sondern als Befehlsbytes interpretiert, die besondere Reaktionen im FDC auslösen. 
Bekommt der FDC beim WRITE TRACK-Befehl eines der folgenden Bytes übermittelt, so 
werden die nachstehend beschriebenen Reaktionen ausgelöst: 


Byte 

1 Funktion 

$00...$F4 

Schreibe normales Byte $00...$F4 

$F5 

Schreibe $A1 mit fehlenden Taktflanken und starte 


CRC-Prüfsummenbildung 

$F6 

Schreibe $C2 mit fehlenden Taktflanken 

$F7 

Schreibe Inhalt des Priifsummengenerators auf Disk (2 CRC-Bytes) 

$F8...$FF 

Schreibe normales Byte $F8...$FF 


Diese Angaben gelten für die Betriebsart “doppelte Schreibdichte” (MFM-Betrieb). Für den 
Betrieb in “einfacher Schreibdichte” (FM-Betrieb), die beim FDC des ST ja nur über einen 
Eingriff in dessen Hardware eingeschaltet werden kann, haben die Bytes $F8..$FF noch eine 
besondere Funktion. Darauf soll hier jedoch nicht weiter eingegangen werden. 

Mit diesen Informationen läßt sich also nun eine komplette Spur im Speicher nachbilden, wel¬ 
che dann mit dem WRITE TRACK-Befehl auf Disk geschrieben werden kann. 

Beim ST sieht so eine “Spur im Speicher” dann wie in Abbildung 8.8 aus. 

Hat man auf der Disk erst mal eine solche S truktur aufgebracht, kann der FDC nun die nötigen 
Markierungen und Synchronisationsinformationen für die sektorweise Datenspeicherung fin¬ 
den. 

Eine ganze Spur im Griff - READ TRACK 

Mit dem READ TRACK-Befehl wird der FDC aufgefordert, den kompletten Inhalt der Spur, 
über welcher der Kopf gerade positioniert ist, zu lesen. 

Alle Bytes, einschließlich GAPs (Lückenbytes zur Synchronisation), ID-Felder, DAMs und 
natürlich Datenbytes werden, beginnend mit der fallenden Flanke des Indexpulses, bis zum 
nächsten Indexpuls innerhalb einer Diskumdrehung gelesen! 

Das Ende der Operation wird wie gehabt per Interrupt und durch Löschen des “BUSY”-Bits 
gemeldet. 

Ein evtl, aufgetretener “Lost data”-Fehler durch nicht rechtzeitiges Reagieren auf die DRQ- 
Signalisierung wird natürlich wieder im Status-Register angezeigt. 
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wiederholt sich für jeden Sektor 
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Fehler bei der Befehlsausführung - Der Bug bei READ TRACK 

Für Diagnoseanwendungen wäre der READ TRACK-Befehl geradezu ideal, wenn er denn 
korrekt funktionieren würde! 

Und an den Fehlfunktionen ist der sogenannte Address Mark-Detector des FDC schuld, der 
bei diesem Befehl ständig eingeschaltet ist. Der AM-Detector des FDC ist zuständig für das 
Erkennen jener bereits beim WRITE TRACK erwähnten Bytes, die mit fehlenden Taktin¬ 
formationen ($A1 und $C2) geschrieben werden. 

Zwar beginnt der FDC mit der fallenden Flanke des Indeximpulses mit dem Lesen der Daten. 
Jedoch fängt er meist mitten in einem Byte an, da der FDC in dem eintreffenden Bitstrom vom 
Laufwerk zunächst nicht erkennen kann, wo denn ein Byte anfängt und wo es aufhört. Die 
ersten Bytes der Spur werden also falsch eingelesen. 

Erst durch Erkennen des ersten Markierungsbytes (durch die fehlende Taktinformation ja 
besonders herausragend) rastet die Synchronisation ein. Leider kümmert sich der ständig akti¬ 
ve AM-Detector anscheinend nicht um bereits erkannte Bytegrenzen und rastet sich auch 
immer dann neu ein, wenn er in einer einlaufenden Bitfolge meint, wieder ein Markierungsbyte 
($A1 oder $C2) erkannt zu haben. 

Durch diese zusätzlichen vermeintlichen Markierungsbytes synchronisiert sich der FDC viel 
öfter auf Markierungen, die eigentlich gar keine sind und damit dann auch falsch! 

Fazit: Den Befehl READ TRACK am besten gar nicht benutzen! 


Kommandos des Typs IV 

Manchmal ist er (der FDC) kaum zu halten - Der FORCE INTERRUPT-Befehl 

Nun zum letzten Kommando des Floppy Controllers. Es läßt sich nicht den vorhergehenden 
Typen I..III zuordnen und bekommt damit eine eigene Typzuordnung. 

Mit dem FORCE INTERRUPT-Kommando wird eine laufende Operation abgebrochen. Die¬ 
ser Befehl wird hauptsächlich benutzt, um ein READ/WRITE MULTIPLE SECTORS-Kom- 
mando zu unterbrechen oder um das Status-Register auf Typ I-Statussignalisierung zurückzu¬ 
schalten. Bei Typ II..m-Befehlen haben einige Status-Bits ja eine andere Bedeutung als bei 
Typ I-Kommandos. FORCE INTERRUPT kann jederzeit an den FDC gesendet werden. Über 
die Bits 2 und 3 des Befehlsbytes wird dem FDC mitgeteilt, wann er denn die laufende Opera¬ 
tion abwürgen soll. Folgende Möglichkeiten gibt es: 
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Befehlsbyte 

Funktion 

$D8 

Sofortige Unterbrechung 

$D4 

Unterbrechung bei nächstem Indeximpuls 

$D0 

Keine Interruptsignalisierung, aber Operation trotzdem abbrechen 


(Clear Immediate Interrupt) 


Empfängt der FDC ein FORCE INTERRUPT-Kommando, so geht der INTRQ-Anschluß auf 
High, sobald die Bedingung für den Interrupt erfüllt ist. {Nein! Diesmal braucht der FDC das 
“BUSY”-Bit nicht setzen, es ist ja von der zu unterbrechenden Operation noch auf High und 
wird durch FORCE INTERRUPT zurückgesetzt!) 

Beim $D4-Interrupt (Indeximpuls Interrupt) geht der INTRQ-Anschluß (Pin 28 des FDC) also 
beim nächsten Indeximpuls auf High (gut zur Drehzahlmessung geeignet!). Wird ein $D8- 
Interrupt (Immediate Interrupt) ausgelöst, “springt” INTRQ sofort nach Empfang des Befehls 
auf “High”. 

Das führt zu der Frage, wann denn die INTRQ-Leitung normalerweise wieder zurück auf Low 
geht? Interrupts treten ja nicht nur per FORCE INTERRUPT, sondern auch nach jeder abge¬ 
schlossenen Operation auf. 

Das “Löschen” der INTRQ-Leitung geschieht sozusagen automatisch durch Auslesen des 
Status-Registers oder beim Laden des Command-Registers mit einem neuen Befehl. Aber wie 
immer gibt es auch hier eine Ausnahme von der Regel. Nach einem “FORCE Immediate 
INTERRUPT” läßt sich nur durch einen SDO-Interrupt (Unterbrechung ohne Unterbrechungs- 
Signalisierung) die INTRQ-Leitung löschen (das ist dann die Unterbrechung der Unterbre¬ 
chung)! 

Bevor man nach einem FORCE INTERRUPT wieder ein Kommando an den FDC gibt, sollte 
man mindestens 16 ps warten. Wenn nicht, wird FORCE INTERRUPT nicht ausgeführt! 


Beim ST ist alles ganz anders - 
Die FDC-Programmierung 

Nein, ganz so schlimm ist es nun doch nicht. Man hat jedoch nicht die Möglichkeit, direkt auf 
die FDC-Register zuzugreifen. 

Zwischen CPU und FDC hat ATARI den DM A-Baustein (DMA=Direct Memory Access oder 
Datentransfer Mal Anders) gesetzt. Das hat den großen Vorteil, daß die CPU z. B. bei 
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Diskzugriffen nicht ständig an der DRQ-Leitung des FDC horchen muß, ob wieder ein 
Datenbyte vom FDC abgeholt oder dorthin gebracht werden muß. 

Das erledigt die DMA-Binheit viel eleganter. Sie braucht nur zu wissen, wie viele Sektoren 
(Bytes) ab welcher Adresse im Speicher auf Disk geschrieben oder von dort eingelesen werden 
sollen, und schon “geht die Post ab”. 

Wie im Prinzip eine FDC-Operation unter Zuhilfenahme der DMA-Einheit abläuft, soll hier 
kurz erläutert werden. 

Eine Beschreibung der einzelnen Register des DMA-Bausteins sind im Teil II, Kapitel 1, “Die 
Zentraleinheit”, zu finden. 

- VBlank-Diskroutine vom DMA- und FDC-Baustein femhalten (“flock”<>0 setzen! Das 

muß natürlich, wie die gesamte FDC-Programmierung, im Supervisormodus geschehen, 
da “flock” (Adr. $43E) im Supervisor-RAM liegt!). 

st flock ; "flock" auf <> setzen 

Floppy-Laufwerk und -Seite über Port A des PSG (Programmable Sound Generator) 
selektieren. Man benutzt dazu die XBIOS-Funktion #29 (“Offgibit”) und #30 (“Ongibit”). 

Die Steuerleitungen zum Laufwerk sind Low-aktiv, also wird mit einem Low (= Bit im 
Port A löschen) auf der entsprechenden “Drive select”- bzw. “Side select”-Leitung die 
Laufwerks-/Seiten-Auswahl durchgeführt! 

Funktion der Bits zur Disksteuerung im Port A des PSG: 

Bit 0: 0 = Seite 1, 

1 = Seite 0 angewählt 

Bit 1:0= Drive A selektiert 

Bit 2:0= Drive B selektiert 

Beispiel: 

move.w #$07,-(SP) ; Beide Drives deselektieren 

move.w #$1E,-(SP) und Seite 0 an wählen 

trap #14 ; "Ongibit" aufrufen 

addq.l #4, SP 


move.w 


#$FA 


; Seite 1 und Drive B selektieren 
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move.w #$1D 

trap #14 ; "Offgibit" aufrufen 

addq.l #4, SP 


Der DMA-Einheit muß mitgeteilt werden, wo die zu schreibenden/lesenden Daten im 
Speicher stehen bzw. nach dem Lesen von der Disk stehen sollen. 

Die Anfangsadresse dieses Speicherbereichs wird der DMA-Einheit im DMA-Base- und 
Counter-Register byteweise übergeben. 


$FF8609 

High-Byte 

("dmahigh") 

$FF860B 

Mid-Byte 

("dmamid") 

$FF860D 

Low-Byte 

("dmalow") 

Achtung! 

Hierbei ist wichtig, daß die Adresse in der Reihenfolge Low-Byte -> 
Mid-Byte -> High-Byte an das DMA-Base-und Counter-Register über¬ 
geben wird. 

Beispiel: 

move.1 

#STRTADR,d7 

; Anfangsadr. für DMA holen 

move.b 

d7,dmalow 

; Low-Byte setzen 

asr.l 

#8,d7 

; Um 1 Byte nach rechts schieben 

move.b 

d7,dmarrdd 

; Mid-Byte setzen 

asr.l 

#8, d7 

; Um 1 Byte nach rechts schieben 

move.b 

d7,dmahi 

; High-Byte setzen. 


- Der 32-By te FIFO-Buffer der DMA-Einheit muß gelöscht werden. Das geschieht durch 

“Kippeln” mit Bit 8 im DMA-Mode-Register (“fifo” an Adr. $FF 8606). 

Gleichzeitig wirdmitdiesem Biteingestellt, in welche Richtung der DM A-Datentransport 
denn laufen soll. 

$90, $190, $90 Wenn diese Word-Folge ins DMA-Mode Register geschrieben 
wird, ist anschließend der FIFO-Buffer gelöscht und der DMA- 
Baustein auf “Lesen” programmiert. 

$190, $90, $190 Diese Word-Folge löscht ebenfalls den FIFO-Buffer, schaltet 
die DMA-Einheit jedoch auf schreibenden DMA-Zugriff. 
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Beispiel: 


lea 

fifo,A5 

move.w 

#$190,0(A5) 

move.w 

#$90 ,0(A5) 

move.w 

#$190,0(A5) 


; Zum Code sparen 
; FIFO-Buffer löschen 
; und DMA-Baustein auf 
; LESEN schalten 


Ein Transfer von Daten zwischen Speicher und FIFO-Buffer im DMA-Baustein findet 
immer nur statt, wenn mindestens 16 Bytes im FIFO “aufgelaufen” sind. Darunter tut sich 
überhaupt nichts. 

Bei Sektorgrößen von 512 Bytes gibt es da keine Schwierigkeiten. Will man jedoch z. 
B. nur ein ID-Feld von Disk lesen (6 Bytes), so kommen diese sechs Bytes gar nicht erst 
im Speicher an. Da hilft nur eins: Mehrere ID-Felder lesen. 

- Die Zahl der zu transportierenden Datenblöcke zu 512 Bytes (Sektoren) wird der DMA- 
Einheitim Sector-Counter-Register (“diskctl” an Adr. $FF 8604) mitgeteilt. Bei READ/ 
WRITE TRACK sind das ca. 6250 Bytes, also rund 13 Blöcke. 

Beispiel: 

move.w #13,diskctl ; 13 Sektoren übertragen 

- Nun wird beim DMA-Chip um “Audienz” beim FDC gebeten, d, h., im DMA-Mode- 
Register wird durch Löschen von Bit 4 die “Durchreiche” zu den FDC-Registem geöff¬ 
net. Durch diesen Kniff wird statt des Sector-Counter-Registers unter Adr. $FF 8604 
(“diskctl”) ein Register des FDC zugänglich. 

Welches FDC-Register nun unter “diskctl” erscheint, wird durch die Bits 1 und 2 des 
DMA-Mode-Registers bestimmt. Diese steuern nämlich die Adreßleitungen, mit denen 
der DMA-Baustein dem FDC-Chip mitteilt, welches Register dieser denn bitte schön 
zum Zugriff bereithalten soll. 

Die auf der nächsten Seite folgenden Kommandoworte für das DMA-Mode-Register 
wählen eines der FDC-Register aus. 

Wenn nach dem Setzen der FDC-Register schreibender DMA-Betrieb vorgesehen ist, 
muß zusätzlich das Bit 8 im DMA-Mode-Register gesetzt werden (siehe auch weiter 
vom, bei der Beschreibung für das Löschen des FEFO-Buffers). 
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Word im DMA- 

angewähltes Register 

Mode Register 

des Floppy Controllers 

$(1)80 

Command/Status-Register (Read=Status) 

$(1)82 

Track-Register 

$(1)84 

Sector-Register 

$(1)86 

Data-Register 


Die Register des FDC werden auf die für die gewünschte Operation erforderlichen Werte 
gesetzt (Track-, Sector-Register). 


Beispiel: 



move.w 

#$86,fifo 

; Zugriff auf Data-Register 

move.w 

#$29,diskctl 

; Track-Nr. $29 ins Data-Register 

move.w 

#$80,fifo 

; Zugriff auf Command-Register 

move.w 

#$14,diskctl 

; SEEK-Befehl mit Verify an FDC 


- Das Ende des Kommandos wird dann vom FDC per Interrupt an den MFP, Port 15, signa¬ 
lisiert. Also empfiehlt es sich, von Zeit zu Zeit Bit 5 des Port Registers des MFP (“gpip” 
an Adr. $FF FA01) zu testen. Bei Low von Bit 5 des Ports ist der FDC fertig. 

- Das DMA-Status-Register (“fifo” an Adr. $FF 8606, READ) gibt Auskunft, ob der 
Datentransfer über den DMA-Baustein ordnungsgemäß abgelaufen ist. Interessant ist 
nur Bit 0. Bei einem Fehler ist dieses auf Low. Die weitere Bitbelegung ist bei der Be¬ 
schreibung der DMA-Register zu finden (Teil U, Kapitel “Die Zentraleinheit”). Vor Zu¬ 
griff auf das DMA-Status-Register sollte It. Atari-Vorgaben überdas DMA-Mode-Regi- 
ster der Zugriff auf das Sector-Counter-Register eingestellt sein (Bit 4 im DMA-Mode 
Register gesetzt). 

Beispiel: 

move.w #$90,fifo ; Sector-Cnt.-Reg. selektieren 

move.w fifo,D7 ; DMA-Status -> Register D7 


Aber nicht nur bei der DMA-Operation kann ein Fehler aufgetreten sein. Deshalb schnell 
noch das FDC-Status-Register ansehen. Dazu muß dieses natürlich erst wieder in der 
“Durchreiche” der DMA-Einheit erscheinen. Also wird mit den bereits vorgestellten 
Kommandowörtemüber das DMA-Mode-Register das FDC-Status-Register angewählt. 
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Beispiel: 

move.w # $80,fifo 

raove.w diskctl,D7 


; FDC-Status-Reg. selektieren 
; FDC-Status -> Register D7 


Wenn wir fertig sind, dürfen die VBlank-Diskroutinen nun wieder auf die DMA-Einheit 
zugreifen (“flock” auf 0 setzen) 

clr.w flock ; "flock" = 0 setzen 
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Kapitel 9: Das Atari 

Computer System Interface (ACSI) 


Die Computer der ST-Serie verfügen zusätzlich zu den schon mehr oder weniger üblichen 
Standard-Schnittstellen über eine Atari-spezifische Schnittstelle: den ACSI-Bus. Atari hat 
hier eine Schnittstelle zum Anschluß von “intelligenten” schnellen Peripheriegeräten wie z. 
B. Harddisks, Laserdrucker oder CD-ROMs definiert. 

Der ACSI-Bus besteht im wesentlichen aus einem bidirektionalen 8-Bit-Datenbus und einigen 
Steuer- und Meldeleitungen. Sein Verhalten und das verwendete Protokoll ähneln stark dem 
des SCSI-Busses (Small Computer System Interface-Bus). ATARI hatden SCSI-Bus auf seine 
Anforderungen zurechtgestutzt und verwendet nur SCSI-Kommandos der Klasse 0, wegen 
einer Abweichung im ersten Befehlsbyte. 

Die Betreuung dieser Schnittstelle liegt im ST bei der DMA-Einheit. Deshalb sind lt. Atari- 
Spezifikation auch Datentransfer-Geschwindigkeiten von über 8 MBit/s möglich. Abbildung 
9.1 skizziert kurz die Komponenten am ACSI-Bus. 

Erforderlich ist zunächst der Initiator. Im Gegensatz zum SCSI-Bus gibt es beim ACSI-Bus 
nur einen davon und das ist der ST. Er verwaltet den ACSI-Bus. 


Initiator 


Devicel |Device| [Devicel [Device 


Device 



Device 


Device 


Device 


Device 


Abb. 9.1: Der ACSI-Bus mit seinen verschiedenen Komponenten 
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Bis zu acht Targets (Zieleinheiten) sind möglich. Ein Target enthält einen eigenen Controller 
zur Steuerung der zum Target gehörigen Geräte (z. B. Harddisk). Dabei ist es durchaus denk¬ 
bar, daß ein Target mehrere Geräte (z. B. Festplatten) steuert. 

Folgende Eigenschaften müssen die angeschlossenen Targets aufweisen: 

- Ein an ein Target gesandtes Kommando darf nicht “in der Luft hängen bleiben”, bis z. 
B. der Controller im Target bereit ist. Mit Ausnahme des letzten müssen alle Bytes eines 
Kommandoblocks durch einen Interrupt vom Target quittiert werden. 

Ein “DRIVENOT READY”-Error muß also sofort nach Empfang gesendet werden, oder 
der Initiator erklärt das angesprochene Target für “nicht anwesend”. 

- Jedes Target testet sich nach einem RESET selbst und muß alle erforderlichen Grund¬ 
einstellungen vornehmen. Ein eigenes Selbsttest-Kommando gibt es nicht. 

Der Initiator kann nach einer festgelegten Zeit “Timeout” signalisieren und (sollte) einen 
RESETfür dasTargetmitdem“Timeout”-Fehlerauslösen (können). Ein softwaremäßiger 
RESET einzelner Targets durch den ST ist jedoch nicht möglich. Wenn RESET, dann 
nur per Druck auf die RESET-Taste des ST und für alle Targets. 

- Wenn ein Target eine Operation abgeschlossen und zum Abschluß ein Statusbyte gesen¬ 
det hat, ist der ACSI-Bus freigeschaltet. 

Als ACSI-Busanschluß am ST benutzt ATARI eine 19pol. Buchse des Typs “DB 19S”. Sie 
sieht zwar ähnlich wie der Centronics-Anschluß aus, es besteht jedoch durch die unterschied¬ 
liche Polzahl keine Verwechslungsgefahr. 

Der SCSI-Bus verwendet hingegen eine 50polige Verbindungsleitung zwischen den einzel¬ 
nen Komponenten, wobei eine große Zahl der Leitungen als Masseleitungen dienen und somit 
als Abschirmung gegen Störeinstrahlungen. 

Diese bei Atari fehlenden Masseleitungen führen dazu, daß die Signalleitungen kurz ausfallen 
müssen, um Störeinstrahlungen gering zu halten. Zwischen einzelnen Devices sind maximal 
24 Inch (ca. 60 cm) zulässig. Die Gesamtleitungslänge darf ca. 1,8 m nicht überschreiten, wo¬ 
bei nicht mehr als vier Targets am ACSI-Bus angeschlossen sein dürfen. 

Die Belegung der Buchse und die Einbindung des ACSI-Busses in die ST-Hardware zeigt der 
nachfolgende Schaltungsauszug. 

Auf dem ACSI-Bus wird mit TTL-Pegeln gearbeitet. 
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Die einzelnen Anschlüsse habe dabei folgende Funktion: 


RESET Mit einem Low auf dieser Leitung werden die angeschlossenen Targets vom 
Initiator zuröckgesetzt. Das RESET-Signal ist 12 psec “lang” aktiviert. 

RAV Damit signalisiert der Initiator die Datentransportrichtung. Bei Low schreibt 

der Initiator an ein Target. Liegt hier High, erwartet der Initiator Informationen 
von einem Target. Das Signal wirkt nur bei der Command-Phase (dazu später 
mehr). Das Handshaking während des Datenaustauschs läuft über ACK und 
DRQ. Die gewünschte Datentransportrichtung wird dem Target während der 
Command-Phase über die gesendeten Command-Bytes “beigebracht”. 


ACK Auch dieses Signal ist wieder Low-aktiv und an die Targets gerichtet. Hiermit 

quittiert der Initiator ein _DRQ (Data ReQuest = Bereitschaft zum Datenaus¬ 
tausch) von einem Target. 

CS Dieses Low-aktive Signal wird für das “Chip Select” des Target-Command- 

(während Command-Phase) oder Target-Status-Registers (während Status- 
Phase) benutzt. Wird vom Initiator an die Targets gerichtet. 

Al Vom Initiator an Target gerichtetes Signal. Mit einem Low auf Al wird die 

Command-Phase “eingeläutef’. 


DRQ Während des DMA-Datentransfers (nicht während der Command-Phase!) 

signalisiert das angesprochene Target mit einem Low auf dieser Leitung, daß 
ein weiteres Byte auf den Bus gelegt werden soll (vom Initiator zum Target) 
oder gelegt wird (vom Target zum Initiator). 

INT Während der Command-Phase quittiert das angesprochene Target mit einem 

Low-Impuls auf dieser Leitung den Empfang eines Bytes. Der Abschluß einer 
DMA-Operation auf dem ACSI-Bus und der Beginn der Status-Phase wird 
ebenfalls per Low auf dieser Leitung signalisiert. 

D0..D7 Richtig geraten! Das ist der Datenbus des ACSI. 

Soviel zur Bedeutung der einzelnen Bus-Leitungen. 

Anschließend nun einiges über den Bus-Fahrplan (die einzelnen Bus-Phasen) des ACSI. 

- Der Datentransport erfolgt asynchron und hält sich an ein Request/Acknowledge- 
Protokoll (Datenanforderung mit anschließender Empfangsbestätigung). Für jedes zu 
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übertragende Byte erfolgt ein Handshake (nach dem Schema: Vorsicht, ein Byte kommt! 
Datenbyte übertragen - Empfangsbestätigung geben). 

- Der Informationsaustausch auf dem ACSI-Bus läuft immer nach dem gleichen Schema 
ab. 

Command-Phase -> Data in/-out-Phase -> Status-Phase -> 

Command-Phase -> Data in/-out-Phase ... 

- Ein RESET hat die höchste Priorität und muß immer ausgeführt werden. 

- Die Targets müssen den Bus ständig “im Auge” behalten und auf evtl. Kommandos um¬ 
gehend reagieren. Ein “Timeout” sollte laut Atari nach drei Sekunden erfolgen, nachdem 
bei einem Command-Byte-Transfer keine Bestätigung vom Target erfolgt ist. 

- Ein Target “antwortet” nur, wenn es “angesprochen” wird. 

- Eine laufende Operation eines Targets kann nur per RESET unterbrochen werden. Der 
Initiator sollte per Software ein Resetsignal auf der RESET-Leitung für die Targets 
auslösen können (der ST kann’s nicht! Ein RESET wird nur erzeugt, wenn der ST 
ebenfalls zurückgesetzt wird.) 

- Ein angesprochenesTargethatden Bus für sich, bis es das Status-Byte zurücksendet. Das 
sollte nicht länger als vier Sekunden ab Operationsbeginn auf sich warten lassen, da sonst 
der Initiator ein “Timeout“ erzeugt und das Target für “nicht anwesend” erklärt. Wobei 
die Festlegung der Timeout-Zeit von der Software her erfolgt, die den ACSI-Bus bedient! 

Zur Verdeutlichung der einzelnen Bus-Phasen folgen nun einige Zeitdiagramme. 


Die Command-Phase 

Der Initiator kündigt durch Low aufder“Al”-Leitung eine Command-Phase an. Während der 
Übertragung des ersten Command-Bytes bleibt “AI” auf Low (siehe Abbildung 9.3). 

Mit einem Low auf der “CS”-Leitung signalisiert der Initiator den angeschlossenen Targets 
die Gültigkeit der Daten auf dem Datenbus. Auf der “R/W”-Leitung liegt ein Low, weil Daten 
vom Initiator an die Targets geschrieben werden. 

Alle Targets haben für sich das erste Command-Byte daraufhin zu untersuchen, ob der Initiator 
mit “ihnen sprechen” möchte. Das “auserwählte” Target muß umgehend den Empfang des 
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Command-Bytes bestätigen (mit einem Low-Impuls auf der “_INT”-Leitung). Geschieht die 
Bestätigung nicht rechtzeitig, kann ein “Time-ouf ’ vom Initiator signalisiert werden. Das 
gesuchte Target wird dann als “nicht anwesend” registriert. 


Al 

IHT 

CS 

R/Ü 

Data 
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/ 
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T 
\ I 
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-H fl b— HcH*- 


fi= 60 ns Cnax .3 
B- 25 B ns tnax .3 
C = 2 B ns Cmax.J 


Abb. 9.3: Die Command-Phase 


Hat das angesprochene Target den Empfang des ersten Command-Bytes mit Low auf der 
“_.LNT”-Leitung quittiert, so existiert nun quasi ein festgeschalteter Datenkanal zwischen 
Initiator und diesem Target. Die weiteren fünf Command-Bytes werden mit High auf der 
“Al”-Leitung übertragen. Alle anderen Targets halten sich bis zum Beginn der nächsten 
Command-Phase (die wird ja wieder mit einem Low auf der “ A 1”-Leitung angekündigt) aus 
dem Datenaustausch heraus. 

Beim ST wird der ACSI-Bus von der DMA-Einheit bedient. Mit deren Unterstützung ist so¬ 
wohl ein Einzelbyte-Transfer als auch ein blockorientierter Datenaustausch (ein ganzes Paket 
mit Bytes wird übertragen) möglich. Die Datenbytes werden in der Command-Phase noch per 
“Handbetrieb” (im Einzelbyte-Transfer) übertragen. Der “Turbolader” (Datenaustausch in 
DMA-Betriebsart) wird erst während der “Data in/out-Phase” zugeschaltet! Das angewendete 
Prinzip für den Einzelbyte-Transfer ist das gleiche wie bei der Übergabe von Daten an die 
Register des Floppy-Disk-Controllers (FDC). 

Beim FD C-Registerzugriff kann man ja mit gelöschten Bits 3+4 im DMA-Mode-Register 
(“fifo” an Adr. $FF 8606) eine “Durchreiche” zu einem mit den Bits 1 +2 im DMA-Mode-Regi- 
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ster auszuwählenden FDC-Register öffnen. Die “Durchreiche” ist dabei das sogenannte 
Controller-Access-Register (“diskctl” an Adr. $FF 8604). Siehe hierzu auch Teil H, Kapitel 
1, Abschnitt “DMA im ST”. 

Für einen Einzelbytezugriff auf den ACSI-Bus muß im DM A-Mode-Register dagegen das Bit 
3 gesetzt und Bit 4 gelöscht sein. Wird nun ein Byte in das Controller-Access-Register 
geschrieben, gelangt es von dort direkt auf die Datenleitungen des ACSI-Busses. Hat man 
vorher im DMA-Mode-Register das Bit 1 gelöscht, wurde damit die “Al”-Leitung des ACSI- 
Busses auf Low gezogen, was ja für die angeschlossenen Targets soviel wie “Achtung, das 
erste Command-Byte kommt” bedeutet. Nur für die Ausgabe des ersten Command-Bytes ist 
“Al” auf Low! 

Die Signale “_CS” und “RAV” werden von der DMA-Einheit intern erzeugt. “RAV” legt die 
Datenrichtung fest und ist für die Ausgabe eines Command-Bytes auf Low (es werden jaDaten 
ans Target geschrieben). 

Das angesprochene Target hat den Empfang jedes Command-Bytes dann mit einem Low-Im- 
puls auf der “„INT’-Leitung zu quittieren (sonst “Timeout”!). Dieser Interrupt läuft im ST ja, 
wie schon beim FDC beschrieben, am Port 15 des MFP auf. Der Zustand des Ports 15 kann an 
Adresse $FF FA01 (“gpip”), Bit 5, abgefragt werden. Das letzte Command-Byte wird aller¬ 
dings nicht mehr per Low-Impuls auf der “_INT”-Leitung vom Target quittiert, sondern es 
wird direkt zur nächsten Phase übergegangen! 


Data-in/out-Phase 

Während der Data-in/out-Phase (siehe Abbildung 9.4 und 9.5) steuert die DMA-Einheit des 
ST den Datentransfer selbsttätig. Es wird dabei im Blockmodus gearbeitet (Übertragung von 
Datenbytes in Blocks zu 512 Bytes). 

“Al” ist dabei ständig auf “High”. Die Synchronisation der Datenübertragung und damit die 
Geschwindigkeit wird ausschließlich durch das Target bestimmt. Durch Low auf der 
“_DRQ”-Leitung signalisiert das Target dem Initiator, daß Daten gebraucht werden (in der 
Data-out-Phase) oder daß Daten vom Target geliefert werden können (in der Data-in-Phase). 

MitLow auf der “_ACK”-Leitung quittiert der Initiator, daß Daten nun auf dem Bus bereitge¬ 
stellt sind (Data-out-Phase) oder die Daten vom Target übernommen wurden (Data-in-Phase). 

Wenn man sich die angegebenen Zeiten z. B. bei der Data-out-Phase betrachtet, so läßt sich 
ausrechnen, daß die Zykluszeit zur Übertragung eines Bytes max. 240 ns + 250 ns + 240 ns 
=s 730 ns beträgt. Es können also mindestens 1/730 ns = 1,37 MByte/Sek. übertragen werden. 
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In der Data-in-Phase kann man unter günstigen Verhältnissen sogar ca. 1,8 MByte/Sek. 
erreichen (wenn der Target-Controller da mitmacht)! 



Abb. 9.4: Die Data-in-Phase 



Abb. 9.5: Die Data-out-Phase 
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Die Status-Phase 

Nach Abschluß einer Data-in/out-Phase wird per Interrupt (Low auf der “JNT’-Leitung) das 
Ende dieser Phase signalisiert. Das Status-Byte für die Operation wird dann vom Target an 
den Initiator übermittelt. 


Im ST wird dieses in das Confcroller-Access-Register geschrieben und kann von dort ausge¬ 
lesen werden (“diskctl” an Adr. $FF 8604). Dazu muß natürlich wieder die “Durchreiche” zum 
ACSI-Bus geöffnet werden (DMA-Mode-Register, Bit 3 gesetzt und Bit 4 gelöscht!). 
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Abb . 9.6: Die Status-Phase (Target -> Initiator) 


Der ACSI-Command-Descriptor-Block 

Während der Command-Phase werden dem Target (in der Mehrzahl der Fälle dürfte das z. Zt. 
die Hard-Disk sein) sechs Bytes übermittelt. Dieser Block hat folgenden Aufbau: 

Byte 0 NNNOOOOO 

^-^- Operationscode 

--- Target-Nummer 
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Byte 1 


Byte 2 


Byte 3 


Byte 4 


Byte 5 


DDDBBBBB 



Block-Nummer 

(ffigh-Bits) 

Device-Nummer 


BBBBBBBB 


BBBBBBBB 


LLLLLLLL 


CCCCCCCC 


Block-Nummer 

(Mid-Bits) 


Block-Nummer 

(Low-Bits) 


Block-Anzahl 


Control-Byte 


Die Target-Nummerb&z&icYmet eines der acht möglichen Targets (Target 0..7) am ACSI-Bus. 
Alle angeschlossenen Targets überprüfen direkt nach Eintreffen des ersten Command-Bytes 
anhand dieser Target-Nummer, ob sie angesprochen sind. Das angesprochene Target bestätigt 
dann unmittelbar dem Initiator per „INT-Signalisierung den Empfang und wartet auf die fol¬ 
genden Bytes des Blocks. Die Target-Nummer kann am Target-Controller mit DIP-Schaltem 
oder Jumpern (Steckbrücken) eingestellt werden. 

Der Operationscode enthält den Code für das auszuführende Kommando. Mit den fünf zur 
Verfügung stehenden Bits sind max. 32 verschiedene Kommandos möglich. 

Die Device-Nummer wählt eines von acht möglichen Geräten des T argets aus, auf welches sich 
das Kommando beziehen soll. Ist das Target ein Hard-Disk-Controller, so könnte damit eins 
von maximal acht Hard-Disk-Laufwerken angesprochen werden. 

Die unteren fünf Bits und die folgenden 16 Bits der Commando-Bytes 2+3 bilden eine 21 Bit 
Block-Nummer für einen Datenblock. Im Falle einer Hard-Disk ist das der log. Sektor, auf den 
zugegriffen werden soll. 
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Der log. Sektor wird dann vom Hard-Disk-Controller in eine Zylinder-, Kopf- und phys. 
Sektomummer umgesetzt. 

Das vierte Byte des Command-Descriptor-Blocks enthält die Block-Anzahl. Dieser 8-Bit- 
Wert gibt an, wie viele Blocks (ä 512 Bytes, also z. B. Sektoren einer Hard-Disk) übertragen 
werden sollen. Dieser Wert muß von Null verschieden sein (warum sollte man auch Null 
Blocks = 0 Bytes übertragen wollen?). 

Das fünfte Byte (<Control-Byte ) ergänzt den Operationscode des Command-Descriptor- 
Blocks um evtl, spezielle Informationen. Es ist jedoch bei den Hard-Disk-Commands unbe¬ 
nutzt und auf Null gesetzt. 

Nachstehend ist der Befehlssatz wiedergegeben, den der Adaptec-Controller in der Hard-Disk 
SH204/SH205/MEGAFILE 30/60 mindestens verstehen sollte, Für die Bezeichnung der Bits 
im Command-Descriptor-Block werden die folgenden Buchstaben benutzt: 

N = Target-Nummer B = Block-Nummer 

D = Device-Nummer L = Block-Anzahl 

Der Befehlssatz des Hard-Disk-Controllers 

Befehl: Test Drive Ready ($0) 

Byte 0: NNN00000 

Byte 1: DDD00000 

Byte 2: 00000000 

Byte 3: 0 0 0 0 0 0 0 0 

Byte 4: 00000000 

Byte 5: 00000000 

Testet, ob die Device-Nr. DDD des Targets NNN angeschlossen und bereit ist. Wenn das der 
Fall ist, wird ein entsprechendes Status-Byte (=0) zurückgeliefert. 

Befehl: Restore to Zero ($1) 

Byte 0: NNN00001 

Byte 1: DDD00000 

Byte 2: 00000000 

Byte 3: 00000000 

Byte 4: 00000000 

Byte 5: 00000000 


Lesekopf auf Spur 0 positionieren. 
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Befehl: 

Byte 0: 

Request sense ($3) 
N N N 

0 

0 

0 

1 

1 

Byte 1: 

D 

D 

D 

0 

0 

0 

0 

0 

Byte 2: 

0 

0 

0 

0 

0 

0 

0 

0 

Byte 3: 

0 

0 

0 

0 

0 

0 

0 

0 

Byte 4: 

0 

0 

0 

0 

0 

1 

0 

0 (4 Bytes zurückliefem!) 

Byte 5: 

0 

0 

0 

0 

0 

0 

0 

0 


Wie wir noch sehen werden, meldet das Target eventuelle Fehler über ein gesetztes Bit 1 im 
Status-Byte. Genauere Informationen über die Art des Fehlers kann man mit diesem Komman¬ 
do erhalten. 


Es werden vier Bytes mit Statusinformationen vom Target-Controller eingelesen. Die vier 
Bytes werden per DMA-Betrieb zum ST übertragen, womit wieder das Problem mit dem 
FIFO-Puffer der DMA-Einheit auftritt (erinnnem Sie sich noch an READ ADDRESS bei der 
Beschreibung des Floppy-Disk-Controllers?)! 

Damit überhaupt Bytes aus dem FTFO-Buffer der DMA-Einheit im Speicher des ST ankom¬ 
men, muß man ja mindestens 16 Bytes übertragen. Also sollte der Befehl mindestens viermal 
ausgeführt werden! 


Die vier gelesenen Bytes haben dabei folgende Bedeutung: 


Byte-Nr 


Inhalt 


Bedeutung 


VFFFFFFF 


X X X B B B B 


Fehlemummer 

log. Blockadresse in den Bytes 
1-3 gültig 


High-Bits der Blockadresse 
Reserviert 


B B B B B B B Mid-Bits der Blockadresse 


B B B B B B B Low-Bits der Blockadresse 
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Im folgenden sehen Sie die in Byte 0 angezeigten Fehlemummem und deren Bedeutung: 


Fehler-Nummer Bedeutung 


$00 

Drive Errors 

No sense (Alles klar! Kein Fehler) 

$01 

No Index (keine Indeximpulse gefunden) 

$02 

No Seek complete (SEEK noch nicht beendet) 

$03 

Write fault (Schreibfehler) 

$04 

Drive not ready (Drive noch bei der Initialisierung?) 

$06 

No Track $00 (Spur $00 nicht zu finden) 

$10 

Controller Errors 

ID ECC Error (ECC-Fehler im ID-Feld) 

$11 

Uncorrectable Data Error 

$12 

(nicht korrigierbarer Fehler im Datenfeld eines Sektors) 

ID Address Mark not found 

$13 

Data Address Mark not found 

$14 

Record not found (Sektor nicht zu finden) 

$15 

Seek Error 

$18 

Data Check in No Retry Mode 

$19 

ECC Error during Verify 

$1A 

Bad Block (Zugriff auf ausgemappten Block) 

$1C 

Unformatted or Bad format 

$20 

Command Errors 

Invalid Command (Ungültiges Kommando) 

$21 

Invalid Address (Ungültige Blockadresse) 

$23 

Volume Overflow (Ungültige Block-Endadresse) 

$24 

Invalid Argument 

$25 

Invalid Drive Number (falsche Gerätenummer) 

$26 

Byte zero Parity Check 

$28 

Cartridge changed (Platte wurde gewechselt) 

$2C 

Error Count overflow 

$30 

(Fehlerzähler hat die vereinbarte Zahl von Fehlem überschritten) 

Sonstige Fehler 

Controller Seiftest failed 
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Befehl: Format drive ($4) 


Byte 0: 

N 

N 

N 

0 

0 

1 

0 

0 


Byte 1: 

D 

D 

D 

G 

G 

0 

F 

0 


Byte 2: 

V 

V 

V 

V 

V 

V 

V 

V 

(Virgin-Byte) 

Byte 3: 

I 

I 

I 

I 

I 

I 

I 

I 

(Interleave-Faktor 

High-Byte) 

Byte 4: 

I 

I 

I 

I 

I 

I 

I 

I 

(Interleave-Faktor 

Low-Byte) 

Byte 5: 

0 

0 

0 

0 

0 

0 

0 

0 



Mit nur einem Befehl kann man die gesamte Harddisk formatieren. Dabei greift der Hard- 
Disk-Controller entweder auf die Format-Informationen zurück, die vorher mit dem Befehl 
“Mode select” übertragen wurden, oder liest sich diese von der Platte. 

Bei gelöschtem “F”-Bit in Byte 1 werden die Sektoren mit einem “ Virgin”-Wert von $6C be¬ 
schrieben, während bei gesetztem “F”-Bit der Wert in Byte 2 als “Virgin”-Byte genommen 
wird. 

Sind die beiden “G”-Bits im Byte 1 gesetzt, so kann dem Festplattencontroller noch eine max. 
1024 Byte lange Liste mit Daten über defekte Stellen auf der Platte im DMA-Betrieb hinterher¬ 
geschickt werden. Der Controller überspringt diese Defektstellen bei der Formatierung. Bei 
dem z. Zt. verwendeten Controller in den Atari-Hard-Disks ist diese Liste wie folgt aufgebaut: 


Byte 

Bedeutung 

$00 

$01 

$02..$03 

Null (Reserviert) 

Null (Reserviert) 

Länge der Defektliste in Bytes 

$04..$06 

$07 

$08..$0B 

Zylindemummer des ersten Defekts 

Kopfnummer (normalerweise 0..3) 

Entfernung d. Defekts v. Indeximpuls in MFM-Bytes 

$0C..$0E 

$0F 

$10..$13 

Zylindemummer des nächsten Defekts 

Kopfnummer 

Entfernung d. Defekts v. Indeximpuls in MFM-Bytes 


Die Bytes 3..4 des Command-Descriptor-Blocks enthalten den Wert für den Interleave-Faktor 
(max. 16). 
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Befehl: 

Read Sector ($8) 







Byte 0: 

N 

N 

N 

0 

1 

0 

0 

0 


Byte 1: 

D 

D 

D 

B 

B 

B 

B 

B 

(log. Blockadresse, 
High-Bits) 

Byte 2: 

B 

B 

B 

B 

B 

B 

B 

B 

(log. Blockadresse, 
Mid-Bits) 

Byte 3: 

B 

B 

B 

B 

B 

B 

B 

B 

(log. Blockadresse, 
Low-Bits) 

Byte 4: 

L 

L 

L 

L 

L 

L 

L 

L 

(Blockanzahl) 

Byte 5: 

0 

0 

0 

0 

0 

0 

0 

0 



Es wird ab der in den Bytes 1 ..3 angegebenen log. Blockadresse die in Byte4 angegebene Zahl 
von Blöcken mit je 512 Bytes gelesen. 


Befehl: 

Write Sector 

($A) 







Byte 0: 

N 

N 

N 

0 

1 

0 

1 

0 


Byte 1: 

D 

D 

D 

B 

B 

B 

B 

B 

(log. Blockadresse 
High-Bits) 

Byte 2: 

B 

B 

B 

B 

B 

B 

B 

B 

(log. Blockadresse, 
Mid-Bits) 

Byte 3: 

B 

B 

B 

B 

B 

B 

B 

B 

(log. Blockadresse, 
Low-Bits) 

Byte 4: 

L 

L 

L 

L 

L 

L 

L 

L 

(Blockanzahl) 

Byte 5: 

0 

0 

0 

0 

0 

0 

0 

0 



Es wird ab der in den Bytes 1..3 angegebenen Blockadresse die in Byte 4 angegebene Zahl 


von Blöcken (mit je 512 Bytes) geschrieben. 

Befehl: Seele Block ($B) 





Byte 0: 

N 

N 

N 

0 

1 

0 

1 

1 


Byte 1: 

D 

D 

D 

B 

B 

B 

B 

B 

(log. Blockadresse, 
High-Bits) 

Byte 2: 

B 

B 

B 

B 

B 

B 

B 

B 

(log. Blockadresse, 
Mid-Bits) 

Byte 3: 

B 

B 

B 

B 

B 

B 

B 

B 

(log. Blockadresse, 
Low-Bits) 
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Befehl: 

Seek Block ($B) 






Byte 4: 

0 

0 

0 

0 

0 

0 

0 

0 

Byte 5: 

0 

0 

0 

0 

0 

0 

0 

0 

Die in den Bytes 1 ..3 angegebene Blockadresse wild angesteuert. 

Befehl: 

Mode 

select ($15) 






Byte 0: 

N 

N 

N 

1 

0 

1 

0 

1 

Byte 1: 

D 

D 

D 

0 

0 

0 

0 

0 

Byte 2: 

0 

0 

0 

0 

0 

0 

0 

0 

Byte 3: 

0 

0 

0 

0 

0 

0 

0 

0 

Byte 4: 

L 

L 

L 

L 

L 

L 

L 

L 

Byte 5: 

0 

0 

0 

0 

0 

0 

0 

0 


(Parameteranzahl 
in Bytes\) 


Dem Controller wird eine Liste mit Parametern für das entsprechende Plattenlaufwerk über¬ 
mittelt. 

Die Länge der Liste steht in Byte 4 des Command-Descriptor-Blocks. 

Per DMA wird dem Controller vom ST dann ein Parameterblock mit folgendem Inhalt ge¬ 
schickt: 


Byte 


Bedeutung 


$00 

$01 

$02 

$03 


Reserviert (=$00) 

Reserviert (=$00) 

Reserviert (=$00) 

Länge der folgenden Extent-Descriptor-List (=8 Bytes) 


Die im Anschluß folgende Extent-Descriptor-List hat folgenden Aufbau: 


Byte 

Bedeutung 

$00 

Density (=$00) 

$01 

Reserviert (=$00) 

$02 

Reserviert (=$00) 

$03 

Reserviert (=$00) 

$04 

Reserviert (=$00) 
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Byte 

Bedeutung 

$05 

Sektorgröße (High-Byte) 

$06 

Sektorgröße (Mid-Byte) 

$07 

Sektorgröße (Low-Byte) 


Die Sektorgröße bei ATARI-Festplatten beträgt 512 Bytes. Anschließend an diese beiden 
Blöcke darf noch eine Liste mit Laufwerksparametem angehängt werden, die folgendermaßen 
aufgebaut sein muß: 


Byte 


Bedeutung 


$00 

$01..$02 
$03 

$04,.$05 

$06..$07 

$08 


$09 


Format-Code (1 -Festplatte, 2=Wechselplatte) 

Anzahl der Zylinder (bei SH205/MEGAFILE 30 normalerweise 612...664) 
Zahl der Schreib-ZLeseköpfe (bei SH205/MEGAFILE 30 = 4) 

Nummer des Zylinders, ab dem mit reduziertem Schreibstrom gearbeitet wird 
Nummer des Zylinders, ab dem mit Schreib-Precompensation gearbeitet wird 
Abstand der Landezone vom ersten (oder letzten) Datenzylinder. Bei gesetztem 
Bit 8 liegt die Landezone am äußeren Rand der Platte, sonst jenseits der inner¬ 
sten Spur. Die unteren sieben Bits geben an, wie viele Zyl inder vom ersten/letz¬ 
ten Datenzylinder entfernt die Landezone für die Köpfe eingerichtet ist. 
Steprate. Bei Atari-Hard-Disks sind drei Einstellungen möglich: 


$00 = 3 Millisekunden 

$01 = 28 Mikrosekunden (Buffered Seek!) 

$02 =12 Mikrosekunden (Buffered Seek!) = Standardeinstellung 


$0A 


$0B 


In diesem Byte sind nur die Bits 2 und 3 relevant. 


Byteweit 

Bedeutung 

00000000 

Softsektorierte Wechselplatte 

00000 1 00 

Softsektorierte Festplatte = Standardeinstellung 

00001000 

Hardsektorierte Wechselplatte (?) 

00001100 

Hardsektorierte Festplatte (?) 


Anzahl der Sektoren/Spur. Üblicherweise ist dieser Wert bei der SH205 auf 17 
eingestellt Bei einem Interleave > 1 kann man auch 18 Sektoren/Spur unter¬ 
bringen und so die Plattenkapazität erhöhen. 

Dabei muß man aber mit einem etwas langsameren Zugriff rechnen (wegen des 
höheren Interleave-Faktors). 
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Wenn diese Parameter mit dem Mode-select-Kommando übertragen wurden, kann mit einem 
nachfolgenden Format-Befehl ($4) die Platte mit den eingestellten Parametern formatiert wer¬ 
den. Nach dem Formatieren werden die neuen Parameter in Spur 0 der Platte abgelegt. 


Befehl: 

Byte 0: 

Mode sense ($1A) 

N N N 

1 

1 

0 

1 

0 


Byte 1: 

D 

D 

D 

0 

0 

0 

0 

0 


Byte 2: 

0 

0 

0 

0 

0 

0 

0 

0 


Byte 3: 

0 

0 

0 

0 

0 

0 

0 

0 


Byte 4: 

L 

L 

L 

L 

L 

L 

L 

L 

(Parameteranzahl 

Byte 5: 

0 

0 

0 

0 

0 

0 

0 

0 

in Bytes\) 


Dieser Befehl funktioniert genau umgekehrt wie Mode select. Es werden die Parameter der 
Platte aus der Spur 0 ausgelesen und per DMA an den ST übermittelt. 


Der Stand der Dinge - Das Status-Byte 

Wie ja schon mehrmals vorher erwähnt, wird jede Operation mit dem Senden eines Status- 
Bytes an den ST abgeschlossen. Dieses Status-Byte enthält in den ersten drei Bits die Nummer 
des Targets, von dem das Status-Byte stammt. Die niedrigwertigen fünf Bits enthalten einen 
Error-Code, wobei jedes Bit eine bestimmte Information über den Stand der ausgeführten 
Operation liefert. 

DDDEE EEE Status-Byte 

^^ ^- = 0 (Reserviert) 

- CHECK-Bit (gesetzt, wenn ein Fehler aufgetre¬ 
ten ist) 

—-— CONDITION MET (tritt bei ATARI-Hard- 

Disks nicht auf) 

- BUSY (gesetzt, wenn noch ein Kommando in 

Arbeit war) 

- = 0 (Reserviert) 

_ Target-Nummer, von dem das Status-Byte 

stammt 


Leider wird durch einen Fehler im Hostadapter der SH204 auch bei Fehlem immer ein Status- 
Byte von $00 an den ST übermittelt. Bei der SH205 erhält man ein korrektes Status-Byte. 



Das Atari Computer System Interface (ACSI) 


999 


Der ST ergreift die Initiative 

Eine Datenübertragung mit DMA-Betrieb (Data-in/out-Phase) auf dem ACSI-Bus mit dem 

ST als Initiator läuft nach untenstehendem Schema ab. Weitere Einzelheiten zu den einzelnen 

Registern der DMA-Einbeit sind in Teil II, Kapitel 1, Abschnitt “DMA im ST” zu finden. 

Die Registerzugriffe müssen natürlich (ebenso wie auf die Sytemvariablen) im Supervisormodus 

ablaufen. 

- Um die VBlank-Disk-Routine vom DMA-Baustein femzuhalten, wird “flock” an 
Adresse $43E gesetzt. 

- Das DMA-Base und Counter-Register (“dmahigh” an Adr. $FF 8609, “dmamid” an Adr. 
$FF 860B und “dmalow” an Adr. $FF 860D) wird mit der Anfangsadresse für den zu 
übertragenden Datenblock geladen (Reihenfolge Low-, Mid-, High-Byte beachten!). 

- Löschen des FIFO-Buffers und des DMA-Status-Registers der DMA-Einheit durch 
“Klappern” (0-1-0- oder 1-0-1-Zustandswechsel) mit dem R/W-Bit (Bit 8) im DMA- 
Mode-Register (“fifo” an Adr. $FF 8606). Sinnvollerweise klappert man mit dem R/W- 
Bit so, daß nach dem Löschen des FIFO-Buffers die Datentransportrichtung auch gleich 
richtig eingestellt ist. Der “Turbo-Lader” (DMA-Einheit) bleibt vorläufig noch gesperrt 
(Bit 7 im DMA-Mode-Register gesetzt), indem man einen DMA-Betrieb mit dem FDC 
“vortäuscht”. 

- Im DMA-Sector-Counter-Register (“diskctl” an Adr. $FF 8604) wird der DMA-Einheit 
die “Arbeitsmenge”, d. h. die Anzahl der zu übertragenden 512-Byte-Blocks, mitgeteilt. 
Um Zugriff auf das Sector-Counter-Register zu bekommen, muß im DMA-Mode-Regi¬ 
ster das Bit 4 gesetzt sein! 

Der Command-Descriptor-Block muß ausgegeben werden. Dazu muß die “Durchrei¬ 
che” zum ACSI-Bus geöffnet werden. Also im DMA-Mode-Register das Bit 3 setzen 
(wir wollen an den ACSI-Bus) und Bit 4 löschen (“Durchreiche” öffnen). 

- Ausgabe des ersten Command-Bytes mit Low auf der “Al”-Leitung des ACSI-Busses 
(Bit 1 im DMA-Mode-Register steuert die “Al”-Leitung und muß also in diesem Fall 
gelöscht werden). Warten auf Target-Empfangsbestätigung durch Low auf der INT- 
Leitung (evtl. “Timeout” auslösen), die am MFP, Port 15 aufläuft (Adresse $FF FA01 
= “gpip”, Bit 5 testen!). 


- Ausgabe der weiteren fünf Command-Bytes im “Handbetrieb” (ohne DM A-Hilfe, Byte 

für Byte) mit High auf der “Al”-Leitung (Bit 1 im DMA-Mode-Register gesetzt) und 
Abwarten der Quittierung vom Target über die “JNT”-Leitung (wieder über Bit 5 in 
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“gpip” abfragbar). Nach dem Senden des letzten Kommandobytes kommt zur Quittierung 
kein Signal über “„INT”, sondern erst wenn das Kommando abgeschlossen wurde! 

Für die Ausgabe der Command-Bytes empfiehlt Atari eine “move.l”-Anweisung. Dadurch 
kann man die im Adreßraum des ST unmittelbar hintereinanderliegenden Controller-Access- 
Register (“diskctl” an Adr. $FF 8604) und DMA-Mode-Register (“fifo” an Adr. $FF 8606) 
“gleichzeitig” beschreiben. Es ist wohl schon mal vorgekommen, daß der DM A-Baustein des 
ST bei zwei umnittelbar aufeinander folgenden Word-Zugriffen auf DMA-Mode-Register 
und dann auf das Controller-Access-Register, die CS-Leitung des ACSI-Busses zweimal akti¬ 
viert hat. Das führte dann im Target-Controller verständlicherweise zu einiger Verwirrung. 

Im High-Word des Long-Zugiffs steht dann der Wert für das Controller-Access-Register (der 
auf den ACSI-Bus gegeben wird) und im Low-Word bereits die Einstellung des DMA-Mode- 
Registers für das nächste Command-Byte. 

- Nach Senden des Command-Descriptor-Blocks wird durch Löschen von Bit 7 im DMA- 
Mode-Register der “Turbo-Lader” auf den ACSI-Bus geschaltet. Das wird in der Regel 
mit der Ausgabe des letzten Command-Bytes gleich miterledigt! 

Nun läuft alles weitere nicht mehr “per Hand” sondern über den “Turbo-Lader” (die 
DMA-Einheit des ST), bis das DMA-Sector-Counter-Register auf Null gezählt ist. Es 
sind dann alle vorgesehenen Datenblocks übertragen. Solange darf der DM A-Baustein 
aber nicht gestört werden. 

- Das Ende der DMA-Operation wird durch Low auf der “_INT”-Leitung an den Port 15 
des MFP (“gpip” an Adr. $FF FA01) gemeldet. Die CPU sollte also immer “ein Auge” 
auf diesen Port haben. 

- Zum Testen auf Erfolg oder Mißerfolg der ganzen Aktion wird das Status-Byte des 
Target-Controllers ausgelesen. Dazu ist der “Durchgriff ’ auf das Controller-Access- 
Register durch Setzen des Bits 3 des DMA-Mode Registers zu öffnen (Bit 4 muß gelöscht 
sein). Aus dem Controller-Access-Register (“diskctl” an Adr. $FF 8604) kann nun das 
Status-Byte ausgelesen werden. 

- Der DMA-Status der Operation kann ebenfalls überprüft werden (“fifo” an Adr. $FF 
8606 auslesen). Die Bits 0..2 sind bei korrekt abgeschlossener Operation gesetzt. 

Nun wird wieder auf Floppy-Zugriff umgeschaltet und damit der “Turbo-Lader” vom 
ACSI-Bus getrennt ($0080 ins DMA-Mode-Register schreiben), “flock” wird zurück¬ 
gesetzt, um die VBlank-Interrupt-Routine wieder an die Floppy zu lassen. 

So läuft der Datentransport zwischen ST als Initiator und einem Target ab. 



Teil III 



Die Hardware des TT 


















































































1003 


Kapitel 1: Schneller, höher, weiter - 
Der Prozessor MC68030 


In den ATARITT-Computemfindetsich ein Prozessor der MotorolaMC68030-Serie, Der Sy¬ 
stemtakt für den Prozessor liegt, ebenso wie der des Coprozessors vom Typ MC68882, bei 32 
MHz. 

Der MC68030 ist aufwärtskompatibel zu seinen Vorgängern, verfügt jedoch über einen we¬ 
sentlich höheren Integrationsgrad und eine neue Architektur. 

Hiernureine stichpunktartige Auflistung derEigenschaften und Möglichkeiten des MC68030: 
Harvard-Architektur (intern getrennte Busse für Adressen und Daten). 

- Getrennte On-Chip-Cache-Speicher für Daten und Befehle (je 256 Byte). 

Damit ist die interne, gleichzeitige Bearbeitung von Befehlen und Daten möglich. 

- Integrierte PMMU (Paged Memory Management Unit) zur Umsetzung von Zugriffen auf 
logische Adressen in entsprechende physikalische Adressen (wichtig in Multitasking- 
Systemen!). 

Vollständiger 32 Bit (nicht gemultiplexter!) Adreßbus. 

32-Bit-Datenbus. 

- Erweiterter B us-Controller mit der U nterstützung von drei verschiedenen Busbetriebsarten 
(Asynchron, Synchron und Burst Data Transfer). 

- Direkte Unterstützung des Coprozessors. 

Da die Möglichkeiten der MC68030 sehr vielfältig sind, würde es den Rahmen dieses Buches 
sprengen, auf alle Eigenschaften einzugehen. 

Wer sich intensiv und erschöpfend mit diesem Prozessor beschäftigen möchte, sei auf das 
“MC68030 Enhanced 32 Bit Mikroprocessor User’s Manual” hingewiesen. Auf nahezu “hal¬ 
ber Profibuchstärke” wird dort nur der Prozessor von vom bis hinten beleuchtet, ohne dabei 
noch besonders intensiv auf so “Nebensächliches” wie den Befehlssatz einzugehen! 
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Hardware 

Im Gegensatz zur MC68000-CPU in z. B. den ST(E)-Maschinen reicht ein 64pol. Gehäuse 
längst nicht mehr für alle Anschlüsse aus (die gehen ja allein für den Adreß- und Datenbus 
schon drauf!). Verwendet wird ein quadratisches 13x13 Pin-Grid-Gehäuse mit 122 Anschlüs¬ 
sen ! Eine Vielzahl von Pins dienen der Betriebsspannungszufuhr und dem Masseanschluß, um 
eine bessere Störunterdrückung zu erreichen. 

In der nachfolgenden Abbildung ist dargestellt, welche Signale (nach Funktionen geordnet) 
beim MC68030 herausgeführt sind. 



Abb. 1.1: Prozessorsignale, nach Funktionsgruppen geordnet 
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Hier nun eine kurze Beschreibung der Signale und deren Bedeutung bzw, Verwendung im 

ATARI TT (oder eben auch nicht!): 

Function Codes (FCO .. FC3) Hiermit gibt die CPU bekannt, auf welchen Adreßraum 

(Supervisor Program/Data, User Program/Data us w.) im 
laufenden Buszyklus zugegriffen wird. Beim Function¬ 
code $7 (alle Bits gesetzt) erfolgt ein Zugriff auf den 
sogenannten CPU address space (spezieller Adreßbe- 
reich der CPU). Das passiert unter anderem bei allen 
CPUs der MC680XX-Serie bei der Interruptbestätigung 
und bei den MC68020/030-CPUs während der Ausfüh¬ 
rung von Coprozessor-Operationen. 

32 Bit-Adreßbus (A 0 .. A 3| ) Ausgabe der Zugriffsadresse für den laufenden Buszyk¬ 

lus. Three-state-Ausgänge (Neben Low- und High kann 
der Anschluß auch noch Hochohmig geschaltet wer¬ 
den!). 

32 Bit-Datenbus (D p .. D 3| ) Transport derDaten mit 8,16,24 oder 32 Bit pro Buszy¬ 

klus. Three-state, bidirektional! 

Transfer Size (SIZO, SIZ1) Statussignal über die im laufenden Buszyklus auf dem 

Datenbus übertragenen Bytes (1.. 4 Bytes!). Three-state- 
Ausgang. 

Bus-Steuersignale 

Operand Cycle Start (_OCS) Low-aktives Ausgangssignal, mit dem der Beginn des 

ersten externen Buszyklusses (Zugriff auf RAM, ROM 
usw.) bei einem Operanden -Transfer angezeigt wird. 
Wird nicht im TT verwendet! 

Extemal Cycle Start (_ECS) Hiermit wird der Beginn jedes Buszyklusses angezeigt. 

Low-aktiver Ausgang. Wird nicht im TT verwendet. 

Read/Write (R/_W) Art des Buszyklusses. High bei Read, Low bei Write- 

Zugriff. Three-state-Ausgang. 

Read-Modify-Write Cycle (_RMC) Identifiziert mit einem Low einen Buszyklus, der nicht 

unterteilbar ist. Es wird etwas in die CPU gelesen, dort 
modifiziert und wieder “weggeschrieben”. Three-state- 
Ausgang. Wird nicht im TT verwendet. 
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Adress Strobe (_AS) Auch schon vom MC68000 bekanntes, low-aktives Si¬ 

gnal, mit dem die Gültigkeit der Adresse im laufenden 
Buszyklus angezeigt wird. Three-state-Ausgang. 

Data Strobe (_DS) Low-aktives Signal. Beim Lc.wzyklus wird damit signali¬ 

siert, daß die externe Einheit Daten auf den Datenbus zu 
legen hat. Während eines Schreibzyklusses zeigt die 
CPU mit einem Low die Gültigkeit der Daten auf dem 
Datenbus an. Wird nicht im TT verwendet. 

Data Buffer Enable (_DBEN) Low-aktives Ausgangssignal für Systeme mit externen 

(schnellen) Datenbuffem (so eine Art externe Cache!). 
Damit können diese Buffer freigegeben werden. Wird 
nicht im TT verwendet. 

Data Transfer and Size Acknowledge (_DSACK0, _DSACK1) 

Eingänge, Low-aktiv. Für asynchrone Buszyklen ver¬ 
wendet. 

Bei einem Lesezyklus “sagt” die externe Einheit (z. B. 1/ 
O-Baustein) darüber Bescheid, wenn die gewünschten 
Daten auf dem Datenbus bereitstehen und in welchem 
Format (8-, 16- oder 32-Bit-Format) das der Fall ist. 

Beim Schreibzyklus quittiert die ext. Einheit die Über¬ 
nahme der Datenbits und in welchem Format das gesche¬ 
hen ist. 

Bei z. B. einem Langwort-Lese-Zugriff (32 Bit) auf 
einen 8-Bit-Port wird der Port mit einer “Antwort” von 
_DSACK0 = Low und „DSACKl = High jeden Zugriff 
quittieren. 

Die CPU wird die ersten acht Bits einiesen und einen 
weiteren Zyklus starten, um von diesem Port die näch¬ 
sten 8 Bits zu erhalten. Das geht dann so lange (vier Zyk¬ 
len), bis alle vier Bytes in der CPU angekommen sind! 

Synchronous Termination (_STERM) 

Dieser Eingang wird als Ende-Signal (Synchronous 
Termination) für synchrone Buszugriffe benutzt. 
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Lerezyklus: Mit _STERM auf Low wird der CPU mitge¬ 
teilt, daß die Daten auf dem Datenbus mit der nächsten 
fallenden Taktflanke ge”lachted” (eingespeichert) wer¬ 
den können. 

«Sc/weibzyklus: Mit _STERM = Low signalisiert die ex¬ 
terne Einheit die Übernahme der Daten vom Datenbus. 


Cache-Steuersignale 

Cache Inhibit Input (_CIIN) Mit einem Low an diesen Eingang wird verhindert, daß 

die Daten dieses Lesezyklusses in die internen Caches 
übernommen werden. 


Cache Inhibit Output (_CIOUT) Dieses Low-aktive Ausgangssignal signalisiert an even¬ 
tuelle ext. Caches, die Daten des laufenden Buszyklusses 
zu ignorieren. Wird nicht im TT verwendet. 


Cache Burst Request (_CBREQ) Mit einem Low-Signal fordert die CPU das Auffüllen 

einer Zeile (vier Langworte) im Cache durch Burst- 
Mode an. Three-state-Ausgang. 


Cache Burst Acknowledge LCBACK) 

Die angesprochene Einheit (RAM) kann im Burst-Mode 
arbeiten und istin der Lage, mindestens noch ein Langwort 
für die int. Caches zu liefern. 


Steuersignale für Interrupts 

Interrupt Priority Level (_IPL0 .. _IPL2) 

Low-aktive Eingänge, über die, wie beim MC68000, die 
“Dringlichkeit” des Interrupts signalisiert wird. 

Interrupt Pending (_IPEND) MiteinemLowbestätigtdieCPU.daßsiedielnterruptan- 

forderung intern registriert hat und dieser Interrupt eine 
höhere Priorität besitzt, als die gegenwärtige Interrupt- 
Maske aufweist. 

Bei der nächsten Gelegenheit (wenn intern der nächste 
Befehl an die Reihe kommt) wird dann der Interrupt 
bearbeitet. Wird nicht im TT verwendet. 
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Autovector (_AVEC) Low-aktives Eingangssignal, daß die CPU bitte schön 

einen Autovektor zu erzeugen hat (beim Interrupt-Ack- 
nowledge-Zyklus). 

Steuersignale für die Buszuteilung 

Bus Request (_BR) Ein externer Baustein (z. B. DMA) möchte gern den Bus 

“für sich” haben. Dieser Eingang ist Low-aktiv. 

Bus Grant (JBG) Low-aktiver Ausgang für die Signalisierung, daß der 

Prozessor die Buskontrolle nach Ende des laufenden 
Buszykiusses abgeben wird. (Bestätigung auf das Bus- 
Request-Signal. 

Bus Grant Acknowledge (_BGACK) 

Über diesen Eingang eifährt die CPU, daß der Bus jetzt 
von jemand anders übernommen wurde. Die neue 
Busmaster-Einheit beläßt dieses Signal auf Low, bis sie 
den Bus wieder freigibt. 


Signale für die Bus-Ausnahmesteuerung 


Reset CRESET) 


Halt (_HALT) 


Bus Enror (_BERR) 


Bidirektionaler Anschluß! 

Wenn von außen ein Low-Signal angelegt wird, geht der 
Prozessor in den Grundzustand zurück (Dauer des Si¬ 
gnals mind. 520 Taktperioden). Wenn der Prozessor 
einen RESET-Befehl bearbeitet, bleibt der interne Status 
der CPU erhalten, und an diesem Anschluß wird ein 
Low-Impuls zum Rücksetzen der externen Einheiten 
ausgegeben. 

Mit einem Low an diesem Anschluß wird die CPU 
“aufgeforderf’, alle Bus-Aktivitäten einzustellen. In Ver¬ 
bindung mit dem _BERR-Signal bedeutet das die Auf¬ 
forderung, den letzten Buszyklus nochmal zu wiederho¬ 
len. 

Mit einem Low an diesem Eingang wird der Prozessor 
auf eine ungültige Busoperation hingewiesen (zum Bei¬ 
spiel, weil eineext. Einheit innerhalb einer gewissen Zeit 
nicht auf einen Buszyklus reagiert hat). 
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Signale für Emulator-Unterstützung 

Für manche Emulationen und zur Fehlersuche ist es zwingend notwendig zu wissen, wie weit 
die Abarbeitung von Befehlen im Prozessor gediehen ist (durch die Verwendung der Caches 
ist das nicht so einfach festzustellen). Deshalb sind einige Signale vorgesehen, die dabei 
“behilflich” sind. 


Cache Disable (_CDIS) 


MMU Disable C.MMUDIS) 


Pipeline Refill (JREFILL) 


Mit einem Low an diesem Eingang wird der MC68030 
“angewiesen”, seine internen Caches nicht zu verwen¬ 
den. Die Cacheinhalte werden dabei nicht gelöscht, 
sondern stehen nach Übergang des Signals auf High 
wieder unverändert zur Verfügung. 

Durch ein Low an diesem Eingang wird die interne 
MMU außer Funktion gesetzt. Dabei werden die Einträ¬ 
ge im Address-translation-cache (ATC = Cachespeicher 
für die Adreßübersetzungstabelle) nicht gelöscht. Nach 
Entfernen des Low-Signals (also bei High) steht der 
MMU-Cache wieder unverändert bereit. 

Mit diesem Signal zeigt der Prozessor an, wenn die inter¬ 
ne Befehlspipeline wieder neu gefüllt wird (bei Ände¬ 
rungen im Programmablauf zum Beispiel bei bedingten 
Verzweigungen). Three-state-Ausgang. 


Internal Microsequencer Status (_STATUS) 

Mit einem Low unterschiedlicher Dauer signalisiert die 
CPU an diesem Anschluß, ob sie gerade am Ende einer 
Befehlsbearbeitung ist (Low für einen Taktzyklus), ob 
eine Trace- oder Interrupt-Ausnahmeverarbeitung an¬ 
steht (Low für zwei Taktzyklen) oder daß eine andere 
Ausnahmeverarbeitung begonnen wird (Low für drei 
Taktzyklen). 

Nicht zu vergessen ist natürlich der Taktanschluß, der im TT mit 32 MHz und TTL-Pegel 
gespeist wird. 


Der MC68030 im TT 

Der TT ist von seinem Aufbau her (ROM, RAM usw.) auf 16 MHz ausgelegt. Atari hat jedoch 
schon kurz nach Auslieferung der ersten TT-Rechner mit 16 MHz an Softwarehäuser eine 
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Takterhöhung für die CPU auf 32 MHz vorgesehen. Damit laufen also prozessorinteme 
Vorgänge mit der doppelten Taktfrequenz ab. Bei RAM- und ROM-Zugriffen sind aufgrund 
des restlichen Systemdesigns jedoch entsprechende Waitstates beim Zugriff erforderlich. 

Da das TT -Platinenlayout zunächst für eine 16-MHz-CPU vorgesehen war, ist für die Umrü¬ 
stung auf 32 MHz von Atari eine eigene Aufsatzplatine zur Anwendung gekommen. Auf 
dieser Platine befinden sich sowohl die CPU als auch einige PALs und FlipHops in SMD-B au¬ 
weise zur Anpassung an das “langsamere Umfeld”. Über einen PGA-Stecker wird die Platine 
direkt in die Fassung für den MC68030 auf dem Motherboard gesteckt. Die Zuführung des 32- 
MHz-Taktes erfolgt über eine separate Taktleitung vom Taktoszillator auf der Hauptplatine. 
In Zukunft wird das Platinenlayout des Motherboards gleich für den 32-MHz-Betrieb des Pro¬ 
zessors und des Coprozessors ausgelegt sein. Die Anpassungsplatine entfällt dann. 


Der interne Aufbau des MC68030 

soll hier nur kurz durch eine Übersicht über die Register gestreift werden. 

Im User-Modus stellt sich der MC68030 genau wie der “gute alte” MC68000 im ST(E) dar. 
Die gleichen acht Daten- und acht Adreßregister mit je 32 Bits Breite sind auch hier zu finden. 
Programmzähler und die unteren acht Bits des Statusregisters (das Condition Code-Register) 
sind genauso aufgebaut und zu betrachten wie beim MC68000! 

Es sind jedoch eine Anzahl von neuen Adressierungsarten hinzugekommen, wie z. B. die 
Möglichkeit, sowohl Daten- als auch Adreßregister als Indexregister zu verwenden. In der Su¬ 
pervisor-Betriebsart kommen aber die zusätzlichen Register der CPU erst richtig zum Tragen. 

Eine Besonderheit gegenüber dem MC68000 ist das Vektor Base Register (VBR). Es enthält 
die Anfangsadresse der Tabelle für die Ausnahmevektoren (1 KByte lang). Zu dem Eintrag 
in diesem Basisregister wird dann der Versatz für den angesprochenen Ausnahmevektor dazu¬ 
addiert und so der Pointer auf die Adresse gebildet, in der die Anfangsadresse für die Ausnah- 
meverarbeitungs-Routine abgelegt ist. Damit muß also die Tabelle für die Ausnahmevektoren 
nicht mehr zwingend an der absoluten Adresse $8 beginnen wie beim MC68000 (was sie im 
TOS des TT aber weiterhin tut)! 

Im Supervisor-Modus stehen nun zwei Stackpointer zur Verfügung. Im “normalen” Supervisor- 
Modus, wie er z. B. nach einem RESET eingestellt ist, wird der Interrupt Stackpointer (ISP) 
verwendet. Umschalten auf den Master Stack Pointer (MSP) läßt sich im Supervisor-Modus 
durch Setzen des M-Bits im Status-Register. Die Belegung des Statusregisters ist nur im Sta¬ 
tusbyte (Supervisor-Modus) geändert (erweitert) worden und sieht wie auf der übernächsten 
Seite aus. 
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Mit den Altemate-Function-Code Registern (SFC und DFC) kann unter bestimmten Bedin¬ 
gungen der durch den 32 Bit-Adreßbus auf vier GByte erweiterte Adreßraum nochmal ver¬ 
vielfacht werden. Mit den je drei Bit-Funktionscodes sind damit acht Adreßräume zu je vier 
GByte unterscheidbar (das sollte erst mal reichen!). 


Geschwindigkeitsgewinn durch Caches 

In den auf dem Chip integrierten Caches werden immer ein Teil der bereits verarbeiteten Daten 
und die im Moment in Bearbeitung befindlichen Befehle zwischengespeichert. Das hat den 
Vorteil, daß auf diese Informationen bei nochmaligem Bedarf (z. B. während einer 
Programmschleife) ohne einen externen Buszyklus zugegriffen werden kann! Das spart 
natürlich Zeit und erhöht die Geschwindigkeit nicht unerheblich (um ca. 10..30%). Für das 
Füllen der Caches wird vorzugsweise der sogenannte “Burst fill mode” verwendet. Damit wird 
jeweils immer ein ganzer Cacheeintrag von 128 Bit (vier Langworte) mit einer sehr geringen 
Zahl von Taktzyklen gefüllt (günstigstenfalls in/ww/Taktzyklen, ohne Waitstates, sonst ent¬ 
sprechend länger)! Zu dieser Betriebsweise muß natürlich die Speicherhardware in der Lage 
sein (was im TT teilweise der Fall ist). 

Caches können nach verschiedenen Prinzipien arbeiten, “Voll-assoziativ-Caches” verglei¬ 
chen zur Überprüfung, ob z. B. der Befehl unter einer bestimmten Adresse im Cache vorliegt, 
die gesamte Adresse. Im MC68030 wird nach dem “Teil-assoziativ-Prinzip” gearbeitet. Dabei 
wird immer nur ein Teil der gewünschten Adresse verglichen. Es wird nämlich unter einem 
Cacheeintrag immerein Block von vier Langwords verwaltet. Damit reduziert sich der erfor¬ 
derliche Hardwareaufwand in der Vergleicherlogik nicht unerheblich, ohne einen merklichen 
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Verlust in der Trefferquote und der Geschwindigkeit hinnehmen zu müssen. Der MC68030 
verwendet aus diesem Grunde auch bevorzugt den bereits erwähnten Burst-fill-Modus, um so 
jeweils mit einem schnellen Zugriff auf den externen Speicher einen Cacheeintrag aufzufti- 
schen. 

Ein Cache ist also nur bei wiederholbaren Programmsequenzen effektiv. Dabei darf die 
Sequenzlänge aber nicht die Größe des Cache übersteigen, weil sonst die Cacheeinträge 
ständig überschrieben werden. Gleiches gilt für Sprünge außerhalb der Adreßdistanz des 
Cache. Ein paar Nachteile lassen sich dabei durch gesclv.ckten Umgang mit dem Cache 
Control Register (CACR) und dem Cache Address Register (CAAR) vermeiden. 


0 

0 

WA 

DBE 

CD 

CED 

FD 

ED 


0 

0 

IBE 

CI 

CEI 

FI EI 


WA = Write Allocate 
DBE - Data Burst Enable 
CD = Clear Data Cache 
CED = Clear Entry in Data 

FD = Freeze Data Cache 
ED = Enable Data Cache 


IBE 

CI 

Cache CEI 

FI 

EF 


= Instruction Burst Enable 

- Clear Instruction Cache 
= Clear Entry in 

Instruction Cache 
= Freeze Instruction Cache 

- Enable Instruction Cache 


Das Cache-Control-Register 

(Das High-Word des Registers ist Null!) 

Mit dem Cache Control Register ist das Sperren (ED- bzw. EI-Bit), Einfrieren (FD- bzw. FI- 
Bit) und das Löschen des gesamten Caches (CD- bzw. CI-Bit) möglich. Unter Einfrieren 
versteht man, daß sich der Cache wie ein ROM verhält. Bei Treffern werden wohl die Cache¬ 
informationen gelesen, aber nicht überschrieben. 

Es können auch einzelne Cacheeinträge, die über das Cache Address Register (CAAR) 
bestimmt werden, durch Manipulation mit dem CED- bzw. CEI-Bit gezielt gelöscht werden. 
Durch die spezielle Organisation des Caches ist es lediglich erforderlich, die Bits 1.2 des 
Adreßeintrags in die Bits 1.2 des CAAR einzuschreiben. 

Damit ist der entsprechende Cache-Eintrag zum Löschen identifiziert! Die anderen Bits im 
32-Bit großen CAAR sind für zukünftige Verwendung durch Motorola reserviert (und werden 
zur Zeit noch nicht ausgewertet!). 

Das DBE- bzw. EBE-Bit signalisiert der Bus-Control-Logik des Prozessors, ob der Burst-fill- 
Modus möglich ist. 
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Adressen gibt’s, die gibt’s gar nicht - Die PMMU 

Hauptsächliches Einsatzgebiet für Memory ManagementUnits (MMU)\stdie Adreßumsetzung 
von logischen Adressen in real existierende, also physikalische Adressen, bei Multitasking- 
Systemen. Dabei kommt es halt vor, daß mehrere Prozesse (Tasks) parallel bearbeitet werden 
sollen. Da in Systemen mit nur einem Prozessor dieser sich immer nur zur gleichen Zeit um 
einen Prozeß kümmern kann, muß eine Umschaltung zwischen einzelnen Tasks z. B. zeit¬ 
gesteuert erfolgen. Um die Umschaltzeiten gering zu halten, ist es natürlich von Vorteil, daß 
die Tasks sich im Arbeitsspeicher befinden. Das würde bedeuten, das diese T asks alle an unter¬ 
schiedlichen Adressen stehen müssen und Überlappungen ebenfalls nicht erlaubt sind. 

Da diese Bedingungen sehr einschränkend sind, weicht man auf den Einsatz einer MMU 
zwischen Prozessor und Speicher aus. Diese sorgt dafür, daß unterschiedliche Tasks mit 
gleichen logischen Adressen arbeiten können, welche dann durch die MMU durch Umsetzung 
in entsprechende physikalische Adressen umgerechnet werden. 

Eine weitere Einsatzmöglichkeit für MMUs sind virtuelle Speicherkonzepte. Damit sind Zu¬ 
griffe auf Adressen möglich, die eigentlich gar nicht real (als Halbleiterspeicherstelle) existie¬ 
ren, sondern nur “scheinbar” (virtuell) vorhanden sind. Zugriffe auf solche virtuellen Adressen 
geschehen meistens auf Massenspeicher wie Harddisks. 

Der Zugriff auf so eine virtuelle Adresse führt also zunächst zu einer Fehlersignalisierung, weil 
die Adresse real nichtexistiert. Dann sorgt das Betriebssystem durch eine Ausnahmebehandlung 
dafür, daß die benötigten Daten dieser Speicherstellen vom Massenspeicher in einen freien 
Speicherbereich im RAM geladen werden. Die MMU sorgt dann nach entsprechender Pro¬ 
grammierung dafür, daß der Zugriff auf die virtuelle Adresse auch auf die real existierende 
Speicherstelle im RAM umgerechnet wird! 

Die im MC68030 integrierte MMU benutzt für die Adreßumsetzung Tabellen für die phy¬ 
sikalischen Adressen, die im Speicher angelegt werden. Die logische Adresse dient dabei als 
Index in dieser Tabelle. Damit hier nicht jedesmal ein ext. Buszyklus erforderlich wird, ist zur 
Beschleunigung noch ein Cachespeicher hinzugefügt worden (der Address Translation 
Cache, ATC ), in dem häufig benutzte Umsetzungen aufbewahrt werden (22 Einträge umfaßt 
der ATC!). 

Erst wenn die Umsetzung mittels des ATC nicht vorgenommen werden kann, wird die im 
RAM liegende Tabelle benutzt. Außerdem existieren für Zugriffe auf Speicherblöcke, die 
keiner Umsetzung unterliegen sollen, zwei Transparent Translation Register (TTO und 777). 

Jede einzelne log. Adresse verbraucht für die Umsetzung in ihre physikalische Adresse natür¬ 
lich nicht einen ganzen Eintrag. 
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Ahb. 13: Das Programmiermodell der MMU 


Vielmehr wird der Speicherbereich der CPU in gleich große Blöcke (Pages) unterteilt (beim 
MC68030 können diese 256 Byte..32 KByte gToß sein, im TT-TOS wird die PMMU auf 32 
KByte-Pages eingestellt), und die Adreßumsetzung erfolgt dementsprechend blockweise. 
Deshalb wird die Memory Management Unit im MC68030 auch als Paged Memory 
management Unit (PMMU) bezeichnet. Jede Page von log. Adressen wird also in einen gleich 
großen Block von physikalischen Adressen umgerechnet. Das Ganze läßt sich durch Glie¬ 
derung in mehrere Umsetzungsebenen (maximal fünf sind möglich) sehr flexibel handhaben 
und spart außerdem drastisch Speicherplatz für die Umsetzungstabellen ein. Am Ende der 
“Pointerei” durch die einzelnen Ebenen findet die MMU dann endlich die Adresse der ge¬ 
wünschten Page (als Page-Deskriptor bezeichnet). 

So existieren denn zwei grundsätzliche Typen von Datenstrukturen, sogenannte Deskriptoren. 
Der Page-Deskriptor enthält die gewünschte physikalische Umsetzungsadresse (bzw. die 
oberen 24 Bits davon, die unteren 8 Bits werden von der logischen Adresse genommen!) und 
befindet sich am Ende einer Umsetzungstabelle! Als Tabellen-Deskriptor wird ein Eintrag 
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bezeichnet, der in den oberen 24 Bits die Adreßbits für den Pointer auf eine weitere Deskriptor- 
Tabelle enthält. 

Die beiden Root-Pointer ( CPU-Root-Pointer und Supervisor-Root-Pointer) enthalten dabei 
den Zeiger auf den Beginn der Tabelle im Speicher. Der CPU-Root-Pointer (CRP) wird dabei 
für Anwenderprogramme (User-Modus) und der Supervisor-Root-Pointer (SRP) im Super¬ 
visormodus für (na, raten Sie doch mal? Richtig!) Systemprogramme benutzt. 


uu 

INDEX-LIMIT 
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qDDDDQDDDBD 

0 DT 

Tabellenadresse (PA31 - PA16) 

Tabellenadresse (PA15 - PA4) 

nicht 

benutzt 


LAI 

DT 
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Obere oder untere Seitenbegrenzung 
Deskriptorart 

Grenzwert lür Tabellenindex für diese 
Tabellenadresse 

Tabellenadresse der nächsten Ebene 
oder Seitenoffset, wenn DT=1 


Abb. 1.4: Der Aufbau des Root-Pointers 


Daß diese beiden Pointer 64 Bit groß sind, liegt daran, daß außer dem Pointer auf den Tabellen¬ 
beginn im Speicher auch noch weitere Informationen enthalten sind. Die eigentliche Tabellen¬ 
adresse umfaßt dabei sogar nur 28 Bits, womit sich die Einschränkung ergibt, daß diese Tabelle 
an einer durch 16 teilbaren Adresse beginnen muß. 

Die Bits 32.33 bilden den sogenannten Descriptor type (DT). Ein Wert von $1 deutet dabei 
auf eine Tabelle im Speicher hin, die mit Page-Deskriptoren gefüllt ist. Der Wert von $0 ist 
beim Root-Pointer nicht zulässig; er markiert einen Deskriptor im Speicher als INVALID 
(führt dazu, daß die weitere Tabellensucherei an der Stelle abbricht!). 

Die anderen möglichen Werte für DT deuten darauf hin, daß der Tabellenbereich, auf den 
verwiesen wird, im Short-format (vier Bytes/Eintrag bei DT = $2) oder im Long-format 
(acht Bytes/Eintrag bei DT = $3) vorliegt. Das höchstwertige Bit (LtU- Bit) im Rootpointer 
(wie auch bei einem Long-format-Tabelleneintrag) gibt dann an, ob durch das 15 Bit-Feld in 
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den Bits 48..62 das obere (L/U = 0) oder untere (L/U = 1) LIMIT des Indexes in der Tabelle 
angegeben ist. Was bedeutet, daß z. B. bei L/U = 0 der Index in die folgende Tabelle den 
LIMIT-Wert nicht überschreiten darf. 

In den Deskriptoren, die in der Tabelle im Speicher stehen, existieren je nach Art (wie z. B. 
Short- oder Long-format-Tabellen- bzw. Page-Deskriptoren) noch weitere Steuer- bzw. Sta¬ 
tus-Bits am Ende des oberen Deskriptor-Langworts bzw. am Ende des Short-format-Deskrip- 
tors. Das U -Bit (f/sed-Bit) wird von der MMU gesetzt, wenn der zugehörige Deskriptor für 
eine Adreßumrechnung gebraucht wurde. 

Mit gesetztem IFP-Bit (VFrite Protect-Bit) wird signalisiert, daß auf die letztlich gefundene 
physikalische Adresse nicht geschrieben werden darf. Das gesetzte CI -Bit (Cache /nhibit-Bit) 
sorgt dafür, daß bei Zugriff auf diese Page die Umsetzung nicht in den ATC übernommen wird 
(z. B. weil sich dahinter Hardware-Adressen verbergen, die sich ohne Beeinflussung der CPU 
ändern können). Mit einem gesetzten M-Bit (Modified Bit) gekennzeichnete Page-Deskriptoren 
signalisieren, daß durch einen Schreibzugriff Speicherstellen in dieser Page verändert wurden. 

Das Translation Control Register (TC) besitzt mehrere Bitfelder, die z. B. für das Umschalten 
zwischen CRP und SRP, Größeneinstellung der Pages, Festlegung der Anzahl der Bits, die für 
die Adreßumsetzung benutzt werden sollen, und die Struktur der Umsetzungstabelle verwen¬ 
det werden. 

Die Register TTO und TT1 legen “Fenster” einstellbarer Größe im Adreßraum fest, für die kei¬ 
nerlei Adreßumsetzung stattfinden soll. Dabei kann außerdem festgelegt werden, ob jedes die¬ 
ser Fenster nur für lesende oder schreibende oder beide Betriebsweisen gelten soll. 

\mMemory Management StatusRegister(MMUSR)scti\M!X\c]nfin&ctmanStälu$\nformaAon&r\ 
über die Suche aus Anlaß einer Adreßübersetzung im ATC oder dem Umsetzungsbaum. 

Auf weitere Einzelheiten zur MMU einzugehen wäre zu umfangreich. Dafür empfiehlt sich 
das bereits weiter oben erwähnte “MC68030 Enhanced 32 Bit Mikroprocessor User’s Manu¬ 
al”, wo auf nahezu 100 Seiten die MMU durchleuchtet wird. 

Im TT-TOS beschränkt sich der Einsatz der MMU ohnehin eigentlich nur auf das Simulieren 
des ST-Adreßraums. Das läuft dann darauf hinaus, dem MC68030 einen mehr oder weniger 
zum ST kompatiblen Speicherraum vom 16 MByte vorzutäuschen. So sollen sich eben z. B. 
in den letzten 32 KByte des ST-Adreßraums auch beim TT die ST-Hardwareregister wie¬ 
derfinden, die aber physikalisch eigentlichin den letzten 32 KByte des MC68030-Speicherraums 
liegen (und auch dort nochmals auftauchen!). 





Kapitel 2: Damit’s noch schneller geht - 
Der Coprozessor MC68882 


Im ATARI TT verrichtet neben der MC68030-CPU noch ein weiterer Prozessorbaustein 
seinen Dienst. Er besitzt einen Befehlssatz von “nur” 64 Instruktionen, dafür sind diese aber 
sehr hilfreich, wenn es um schnelle und komplexe Berechnungen geht. Der Coprozessor 
wickelt mathematische Aufgabenstellungen wie z. B. sin(x), log(x) usw, mit einer sehr hohen 
Verarbeitungsgeschwindigkeit und Genauigkeit ab. 

Der Vorteil bei der Verwendung des MC68882 (oder seines Vorgängers, des MC68881) in 
Verbindung mit dem MC68020/MC68030 liegt darin, daß man beim Programmieren in der 
Praxis gar nicht mehr zu unterscheiden braucht, ob der entsprechende Befehl nun durch die 
CPU oder den Coprozessor ausgeführt wird. Die beiden Chips spielen so elegant ineinander, 
daß man meint, nur einen einzigen Prozessor zu programmieren, der auch Fließkommaarithmetik 
beherrscht. 

Motorola hat dabei eine Schnittstelle für die Coprozessor-Anbindung definiert, die ab den Pro¬ 
zessoren der MC68020er-Serie die Kommunikation mit dem Coprozessor regelt. 

Im Gegensatz zum MEGA ST(E) mit nachgerüstetem Coprozessor, braucht der Programmie¬ 
rer die Coprozessor-Interface-Register nicht selbst zu bedienen, um festzustellen, wie weit der 
Coprozessor ist und ob z. B. noch weitere Operanden “rübergeschoben” werden müssen. 


Hardwaremäßige Einbindung des MC68882 beim TT 

Die Anbindung des Coprozessors an einen MC68030 ist relativ einfach zu bewerkstelligen. 
So sind natürlich alle 32 Datenbusleitungen zwischen beiden Chips vorhanden, um nicht durch 
einen zu “schmalen” Bus einen Performance-Verlust zu erzeugen. Für die Registerauswahl 
im Coprozessor sind außerdem die Adreßbusleitungen Al.. A4 an die FPU (= Floating Point 
Unit) angeschlossen. Zur Steuerung des Datenaustauschs werden dann nur noch die Quit¬ 
tungsleitungen JDSACKO und _DSACK1 von der FPU bedient. 

Über die _AS- und _DS-Eingänge erfährt die FPU von der CPU, wann Adreß- und Datenbus¬ 
informationen gültig sind. Die Art des Buszyklusses (Lesen oder Schreiben) wird über die R/ 
_W-Leitung signalisiert. Und über den _CS (= Chip Select)-Anschluß teilt die TTSCU (TT- 
System Control Unit = Baustein für die Generierung und Überwachung von Signalen für die 
Ausnahmeverarbeitung) der FPU mit, wann sie denn angesprochen ist. 
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Weil die FPU die Buszyklen asynchron abschließt, muß diese nicht unbedingt mit dem 
gleichen Takt wie die CPU betrieben werden. 

So sieht denn das (für die 32 MHz-CPU angepaßte) Platinenlayout im TT die Möglichkeit des 
Umschaltens auf 16 MHz FPU-Takt durch Umsetzen einer Lötbrücke (W101 auf 23 = 
16 MH/.'Takt: W101 auf 1 2 = 32 MHz-Takt) vor. 



Abb. 2.1: Hardwaremäßige Einbindung des MC68882 beim TT 
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Abb. 2.2: Blockdiagramm des MC68882 
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Aufbau des MC68882 

Der innere Aufbau des MC68882 ist ähnlich komplex wie der des MC68030. Für den 
Programmierer sind jedoch ohnehin nur die Register von Bedeutung und welche Funktionen 
darüber gesteuert werden können. 

Die MC68882-FPU unterscheidet sich, außer in der Höhe der Taktfrequenz (der MC68881 ist 
in Ausführungen bis max. 25 MHz erhältlich, der MC68882 bis 33 MHz), der optimierten 
Arbeitsgeschwindigkeit, noch durch die Conversion Unit (CU ). Diese erlaubt bereits die Ein¬ 
gabe von weiteren Instruktionen, während die interne Arithmetic Processing Unit ( APU ) noch 
mit der vorherigen Aufgabe beschäftigt ist. 

Von dieser Conversion Unit werden dann z. B. schon die weiteren Operanden angefordert 
(über die Bus Interface Unit der FPU) und vom platzsparenden 64 Bit-Format ins FPU-interne 
80 Bit-Format konvertiert. Handelt es sich z. B. um Datentransportbefehle in eines der acht 
Floating-Point-Register, so wird der konvertierte Operand dort auch schon abgelegt (wenn die 
APU dieses Register nicht gerade selbst verwendet). Bei einem Datentransportbefehl von 
einem der Floating-Point-Register nach “außen” holt die CU den Operanden aus dem entspre¬ 
chenden Register (wenn dieses Register nicht ausgerechnet Ziel der Rechenoperation des 
gerade laufenden Befehls in der APU ist), konvertiert diesen ins gewünschte externe Format 
und bringt ihn “ans Ziel” (natürlich mit CPU-Unterstützung!). 
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Abb. 2.3: Das Programmiermodell des MC68882 
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Zahlenformate beim MC68881/68882 

Die acht Fließkommaregister des MC68881/68882 besitzen je eine Breite von 80 Bit. Damit 
werden Fließkommazahlen als 64 Bit-Mantisse (Bits 0.. 63) mit einem 15 Bit-Exponent (Bits 
64..78) dargestellt. Das höchstwertige Bit dient als Vorzeichenbit für die Mantisse! Die Zahlen 
können jedoch auch in anderen Formaten dargestellt werden, die dann von der FPU entspre¬ 
chend in das interne Format konvertiert werden. Da ja intern von der FPU ohnehin das 80-Bit- 
Format verwendet wird (auch als Extended Precision Format bezeichnet), können natürlich 
auch Operanden unterschiedlichen Formats verknüpft werden! Die MC68882-FPU unter¬ 
stützt dabei die folgenden (auch im IEEE Standard for Binary Floating-Point Arithmetic ver¬ 
einbarten) Formate: 


Integer Data Format (Ganzzahl-Format) 

Hier sind die bereits vom MC680XX bekannten Datenformate in Zweierkomplement-Dar¬ 
stellung (höchstwertiges Bit ist Vorzeichenbit) von Byte-, Word- und Longword-Größe ge¬ 
meint. 


Binary Real Data Format (Binäres Realzahl-Format) 

Generell wird hier mit dem folgenden Format gearbeitet: Vorzeichen x Mantisse x 2 &pOKC1 


30 ,22 I 0 



8 Bit- 

23 Bit- 


Exponent 

Nachkommateil 


1 — Vorzeichen des Nachkommateils 



62 

52 

0 


11 Bit- 
Exponent 

52 Bit- 

Nachkommateil 


— Vorzeichen des Nachkommateils 


Single Real 

(Einfache Genauigkeit) 


Double Real 

(Doppelte Genauigkeit) 
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94 

80 

63 

0 


15 Bit- 
Exponent 

Null 


64 Bit- 

Mantisse! 

►-2Z- 


Extended Real 

(Doppelte Genauigkeit) 


Unterstellter Dezimalpunkt! 
— Vorkommastelle 
— Vorzeichen des Nachkommateils 


In allen drei Formaten wird die sogenannte “normalisierte” Darstellung verwendet. Das be¬ 
deutet, daß die Mantisse immer zwischen 1,0 und 2,0 liegt. Damit kann man sich die Eins vor 
dem Komma schenken (und muß sie sich nur denken). 

Es wird also nur der Nachkommateil angegeben. Ausnahme ist hierbei das Extended Real- 
Format, bei dem die Vorkommastelle mit angegeben wird. 

Es existieren auch sogenannte “nicht normalisierte” Zahlendarstellungen. Sie werden für 
Werte nahe dem untersten darstellbaren Zahlenwert verwendet. Dabei ist der Exponent = 0, 
und die Mantisse hat einen von Null verschiedenen Wert. Die Vorkommastelle ist dann aber 
ebenfalls=0 (oder man muß sie sich beim Single Real- und Double Real-Format als Null “den¬ 
ken”)! 


Eine weitere Besonderheit ist der Zahlenwert Null. Er wird durch eine Null im Exponenten 
und in der Mantisse (bzw. Nachkommateil der Mantisse) dargestellt. 

Eine Zahl, die den darstellbaren Wertebereich überschreitet, wird als Unendlich (Infinity) be¬ 
handelt und durch eine Mantisse (bzw. Nachkommateil) von Null und durch den höchstmög¬ 
lichen Wert für den Exponenten gekennzeichnet. 

Ist der Exponent auf Maximum gesetzt und die Mantisse nicht Null, so wird damit ein Resultat 
angezeigt, das mathematisch unzulässig (nicht interpretierbar) ist. Z. B. das Ergebnis aus einer 
Division von Unendlich durch Unendlich! Solche Resultate werden als NANs bezeichnet (Not- 
A-Number!) 

Der Exponent ist bei allen drei Formaten zunächst als vorzeichenlose Ganzzahl zu betrachten, 
zu der allerdings bereits ein Offset addiert ist. Dieser beträgt 127 bei Single Real, 1023 bei 
Double Real und 16383 bei Extended Real. 

Um den Zahlenwert des Exponenten zu erhalten, ist also der entsprechende Offset abzuziehen. 
Der so erhaltene Wert ist dann als Binärzahl im Zweierkomplement zu betrachten. 
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Beispiel: 

Die Dezimalzahl 5 wird als Single Real-Zahl durch einen 32 Bit Long mit dem Wert 
$40AOOOOO dargestellt. Nach Zerlegung in Exponent und Nachkommateil erhält man dann: 

Bits 0..22 bilden den Nachkommateil (20000 kx ) der Mantisse. Wandelt man diese 
Binärzahl (als Nachkommazahl!) in Dezimal um, so erhält man 0,25 de J Da 
ja die Eins vor dem Komma nicht auftaucht, aber “gedacht” werden muß (sie 
ist “implizit” vorhanden!), ergibt sich die komplette Mantisse dann zu l dez + 
0,25. =1,25, ! 

Bits 23..30 bilden den Exponenten (10000001 binär ). In Dezimal sind das 129 dei - Da aber 
darin ein Offset von 127 dez (bei Single Real) enthalten ist, muß dieser 
abgezogen werden, um den Exponenten im Zweierkomplement zu erhalten. 
Somit ergibt sich als Resultat für den Exponenten 129 dcz - 127 dM = 2 dcx . 

Bit 31 ist das Vorzeichenbit des Nachkommateils und hier Null. Damit ist die Man¬ 

tisse als positive Zahl deklariert. 

Die Zahl läßt sich jetzt also als Vorzeichen x Mantisse x 2 Exp ° ne " < schreiben. Das ergibt für 
das Beispiel den Wert von +1,25 x 2 2 =+l,25x4 = +5! (WZBW=Was Zu Beweisen War). 
Die gleiche Zahl als Double Real ergibt sich übrigens zu $40140000 00000000 kx . Sie können 
ja selbst einmal probieren, ob die Umwandlung nach dem Double Real-Schema auch auf die 
dezimale 5 führt (wehe, wenn nicht!). 


Packed Decimal Real Data Format (Dezimal Gepacktes Realzahl- 
Format) 

Die Zahlen werden hierbei als 24stelliger, gepackter String dargestellt. In ein Byte werden 
jeweils zwei Ziffern “gepackt”! Somit werden zwölf Bytes für die gesamte Zahl benötigt. 




3stelliger Exponent 

2 Bits für Unendlich/NAN-Signalisierung (sonst = 0!) 
1 Bit für Exponentenvorzeichen 
1 Bit für Mantissenvorzeichen 
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Die Befehle des MC68881/68882 


Die Kommunikation der CPU mit dem Coprozessor erfolgt nach einem durch Motorola 
festgelegten Protokoll. Dieses Protokoll ist aber im “Befehlssatz” der Prozessoren des Typs 
MC68000/68010 noch nicht vorhanden, sondern steht erst ab CPUs der Baureihe MC68020 
und höher zur Verfügung. Wenn man die FPU in Verbindung mit einer MC68000-CPU (z. B. 
im ST(E)) betreiben will, so muß der Coprozessor als “normaler” Peripheriebaustein ange¬ 
sprochen werden. Für die Abwicklung des Protokolls, bei dem ja eine Menge von Informatio¬ 
nen ausgetauscht werden müssen, stehen 12 FPU-inteme Register zur Verfügung. Das Setzen 
und Auswerten dieser Coprocessor Interface Register (C1R) muß bei einer MC68000er-CPU 
durch ein Programm erfolgen, welches das Kommunikationsprotokoll einhält. Der Programmie¬ 
rer eines MC68020/68030 überläßt diese Arbeit seiner CPU. 

Alle Coprozessorbefehle bestehen aus mindestens zwei Befehlswörtern. Beim ersten Befehls¬ 
wort sind die vier höchstwertigen Bits immer gesetzt, um zu signalisieren, daß es sichum einen 
Coprozessorbefehl handelt. Weil alle Coprozessorbefehle also immer mit $F... beginnen, wer¬ 
den diese auch als Line-F-Befehle bezeichnet. 

Bei MC68000/68010-CPUs lösen solche Befehle infolge des fehlenden (integrierten) 
Kommunikationsprotokolls einen Line-F-Trap aus. Dieser Trap soll dann dazu verwendet 
werden, um mittels eines entsprechenden Trap-Handlers die Coprozessorkommunikation zu 
steuern. Leider hat ATARI in früheren TOS-Versionen diesen Line-F-Trap für eigene Be¬ 
triebssystemaufrufe benutzt! Da blieb einem dann nur noch die Möglichkeit, den nachträglich 
nachrüstbaren Coprozessor “von Hand” über eigene Routinen oder einen “verbogenen” Line- 
F-Handler zu steuern. Letztere Lösung wurde in der c’t 4/1990 recht ausführlich beschrieben! 

Aber nun zu den eigentlichen Coprozessor-Befehlen. Diese lassen sich in fünf Gruppen eintei¬ 
len. 


Datentransportbefehle 
Befehle mit einem Operanden 
Befehle mit zwei Operanden 
Programmsteuerbefehle 
Befehle zur Systemsteuerung 


Datentransportbefehle 

Mit dieser Befehlsgruppe werden Daten bewegt, also Register in der FPU geladen oder 
Registerinhalte der FPU im Speicher oder der CPU abgelegt. Alle Transportbefehle beginnen 
mit dem Mnemonic FMOVE. 
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Weil ja bei Verwendung der FPU noch einige weitere Datenformate hinzukommen, müssen 
diesenatürlich entsprechend imBefehl angegeben werden. Die bereitsbekannten Datenformate 
Byte, Word und Long werden wie gehabt durch die Zusätze “.B”, W” und “,L” hinter dem 
Befehlsmnemonic gekennzeichnet. Mit “,S” erkennt der Assembler ein Single Real-Format; 
“.D” steht für Double Real und “.X” für das Extended Real-Format. 


Packed Dezimal wird durch ein “.P” gekennzeichnet. Außerdem ist hinter der Zieladresse 
noch ein Formatparameter (k-Faktor) im Zweierkomplement (zwischen -64 und+17) anzuge¬ 
ben. Positive Werte bestimmen dabei die Anzahl der Stellen, mit der die Mantisse ausgegeben 
wird. Negative k-Werte bestimmen die Anzahl der Nachkommastellen im “normalen” Zah¬ 
lenformat (also wenn die Zahl nicht in Exponentialschreibweise dargestellt wird). 


Beispiele; 


FMOVE.L d0,FP0 


; Long aus CPU-Reg. DO ins FPO-Reg. laden. 


FMOVE.X FP0,(a0)+ ; Wert aus FPO-Reg. im Extended Real-Format im Spei¬ 

cher ablegen. Pointer steht in CPU-Reg. A0. Anschlie¬ 
ßend Pointer entsprechend inkrementieren. 


FMOVE.P FP7,result{#5) ; FP7-Wert als Packed Decimal in Speicherstelle “result” 

ablegen. Dabei den Nachkommateil mit 5 Stellen ange¬ 
ben, Enthält FP7 also den Wert 12345,67898765, so er¬ 
gibt sich als Ergebnisstring in “result” dann +1,2346 x 
10 " 1 . 


Genau wie bei der CPU gibt es auch bei der FPU die Möglichkeit, mit einem FMOVB-Befehl 
eine ganze Liste von Registerinhalten zu bewegen. Dieser Befehl heißt hier FMOVEM und 
transportiert entweder FP-Datenregisterinhalte im Extended Real-Format (FMOVEM.X) 
oder FPU-Control-Register als Long (FMOVEM.L) zwischen Speicher und FPU. 

Weil in mathematischen Berechnungen bestimmte Konstanten (Kreiszahl 7t, Eulersche Zahl 
e usw.) relativ häufig benötigt werden, hat man diese in ein spezielles Konstanten-ROM der 
FPU “eingebaut”. Mit einem speziellen FMOVECRX -Befehl kann man durch Angabe des 
Offsets in dieses ROM die dort abgelegten Konstanten abrufen. Hier die Offsets der Konstan¬ 
ten in einer kleinen Tabelle: 


Offset 

Konstante 

$00 

Kreiszahl tc 

= 3,14159... 

$0B 

Log, 0 (2) 

= 0,30102... 
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Offset 

Konstante 

$0C 

Eulersche Zahl e = 2,71828... 

$0D 

Log 2 (e) = 1,44269... 

$0E 

Log 10 (e) =0,43429... 

$0F 

0,0 = 0,0! 

$30 

ln(2) = 0,69314... 

$31 

ln(10) = 2,30258... 

$32 

10° 

$33 

10 1 

$34 

10 2 

$35 

IO 4 

$36 

10 8 

$37 

IO' 6 

$38 

10 32 

$39 

10 64 

$3A 

1QI28 

$3B 

1Q256 

$3C 

10 512 

$3D 

IO' 024 

$3E 

J Q2048 

$3F 

JQ4096 


Befehle mit einem Operanden 

Hierbei wird nur ein Eingabe-Operand benötigt, auf den der entsprechende Befehl angewendet 
wird. Dabei ist es aber durchaus möglich, das Ergebnis in einem anderen FP-Register 
abzulegen (Beispiel: “FSIN FP0,FP1” berechnet den Sinus des Werts in Register FPO und 
setzt das Ergebnis dann in Register FP1. Register FPO wird nicht verändert)! 

Eine Besonderheit stellt hierbei allerdings der spezielle Befehl FSINCOS dar. Damit läßt sich 
von einer Zahl gleichzeitig der Sinus und der Kosinus berechnen. 

Dazu ist allerdings erforderlich, daß zwei Zielregister für die beiden Rechenergebnisse ange¬ 
geben werden. 

Beispiel: 

FSINCOS.X FP0,FP1:FP2 ; Sin(FPO) -> FP2!; Cos(FPO) -> FP1! 
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Hier eine Zusammenfassung der möglichen Befehle in einer kleinen Tabelle: 


Mnemonic 

Funktion 

FABS 

Erzeugt den Absolutwert der Zahl (immer positiv!) 

FACOS 

Arcus Cosinus (Umkehrfunktion der Kosinusfunktion) 

FASIN 

Arcus Sinus (Umkehrfunktion der Sinusfunktion) 

FATAN 

Arcus Tangens (Umkehrfunktion der Tangensfunktion) 

FATANH 

Area Tangenshyperbolicus (Umkehrfkt. des Hyperbeltan.) 

FCOS 

Kosinus(X) 

FCOSH 

Hyperbelkosinus(X) 

FETOX 

e x 

FETOXM1 

e x - 1 

FGETEXP 

Liefert den Exponenten der Zahl 

FGETMAN 

Liefert die Mantisse der Zahl 

FINT 

Rundet auf die nächste ganze Zahl auf oder ab 

FINTRZ 

Rundet auf die nächste ganze Zahl ab 

FLOGN 

ln(x) 

FLOGNP1 

ln(x+l) 

FLOGIO 

log 10 (X) 

FLOG2 

log 2 (X) 

FNEG 

Negation 

FSIN 

Sinus(X) 

FSINH 

Hyperbelsinus(X) 

FSQRT 

Quadratwurzel(X) 

FTAN 

Tangens(X) 

FTANH 

Hyperbeltangens(X) 

FTENTOX 

10 x 

FTWOTOX 

2 X 


Befehle mit zwei Operanden 

Bei diesem Befehlstyp werden zwei Eingabewerte benötigt, die verknüpft werden sollen. 

Dabei darf der erste Operand im Speicher, CPU-Register oder in einem FPU-Datenregister 
stehen. Der zweite Operand muß immer in einem FPU-Datenregister zu finden sein! In diesem 
FPU-Datenregister “landet” dann auch das Ergebnis der Operation. 

Auch hier alle Befehle in einer tabellarischen Übersicht: 
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Mnemonic 

Funktion 

FADD 

Addiert zwei Zahlen 

FCMP 

FPn - Quelle. Ergebnis setzt Condition Codes entsprechen 

FDIV 

FPn / Quelle => FPn 

FMOD 

FPn mod Quelle => FPn. Division läßt nur Rest übrig 

FMUL 

FPn * Quelle => FPn 

FREM 

Diff. von FPn z. nächstliegenden Vielfachen des Quellop. 

FSCALE 

FPn x INT(2 <3uri,e ) => FPn 

FSGLDIV 

Division (Ergebnis im Single Real Fonnat) 

FSGLMUL 

Multiplikation (Ergebnis im Single Real Format) 

FSUB 

FPn - Quelle => FPn 


FPn = Datenregister-#n in der FPU 


Programmsteuerbefehle 

Wie in der CPU läßt sich - auch abhängig von bestimmten Bedingungen in der FPU - der 
weitere Programmfluß steuern (verzweigen). So gibt es z. B. die von der CPU her bekannten 
Sprungbefehle auch in Verbindung mit der FPU. Hier wird dann abhängig von den Bedin¬ 
gungsbits im Floating Point Status Register ( FPSR ) verzweigt. 


Befehl 

Operand 

Operation 

FBcc 

<label> 

IF Bedindung cc wahr, THEN GOTO <label> 

FDBcc 

Dn,<label> 

IF Bedingung cc wahr, TUEN NOP 

ELSE Dn := Dn - 1 

IF Dn <> - 1 , THEN GOTO <label> 

FNOP 


No Operation 

FScc 

<ea>* 

IF Bedingung cc wahr, THEN <ea> $FF 

ELSE <ea> := $00 

FTST 

<ea>* 

Zahl testen und FPSR-Condition-Code-Bits entsprechend 


FPn 

setzen 


<ea>’= Steht für “Effektive Adresse”. Diese kann sowohl ein CPU-Datenregister als 
auch eine Speicherzelle sein, auf die mit den von der CPU her möglichen Adres¬ 
sierungsarten zugegriffen werden kann! 

Für die Bedingungen cc in der obigen Tabelle können dann die folgenden Mnemonics ein¬ 
gesetzt werden: 
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Mnemo. 

1 

Mnemo. 

2 

Bedeutung 

EQ 

SEQ 

Gleich 

(Diese Mnemonics sind nur der 

NE 

SNE 

Ungleich 

Vollständigkeit halber in die 32 

F 

SF 

Immer falsch 

möglichen Abfragen mit 

T 

ST 

Immer wahr 

aufgenommen worden!) 

GE 

OGE 

Gleich oder größer 


GL 

OGL 

Größer oder kleiner (also ungleich!) 

GLE 

OR 

Größer, kleiner oder gleich (aber es ist kein NAN!) 

GT 

OGT 

Größer 


LE 

OLE 

Kleiner oder gleich 


LT 

OLT 

Kleiner 


NGE 

UGE 

[Das sind die gleichen Konditionen wie vorher, nur 

NGL 

UEQ 

daß zusätzlich das NAN-Bit gesetzt sein muß. 

NGLE 

UN 

Damit wird zusätzlich ermöglicht, auch Bedingungen 

NGT 

UGT 

zu prüfen, obwohl ein Wert verwendet wurde, der 

NLE 

ULE 

nicht ins gültige Datenformat paßt!] 

NLT 

ULT 

| 11 »J 13 il 



Die Mnemonics vom Typ 1 werden verwendet, wenn aufgrund der Bedingungsabfrage zu¬ 
sätzlich eine Exception ausgelöst werden soll, weil beim Test ein N AN beteiligt war und somit 
eine sogenannte “Unordered condition” aufgetreten ist. Als Folge davon wird das BSUN-Bit 
(Branch/Set on Unordered-Bit) im EXC-Byte des Floating-Point Status Register gesetzt. Die 
Mnemonics des Typs 2 setzen das BSUN-Bit nicht (auch wenn ein NAN beteiligt war)! 


Befehle zur Systemsteuerung 

Mit diesen Befehlen kann z. B. unter bestimmten Bedingungen ein Trap ( FTRAPcc ) ausgelöst 
werden. Dabei sind für cc die gleichen Mnemonics zu verwenden, wie in der vorigen Tabelle 
bereits dargestellt. 

Die ebenfalls zur Systemsteuerung gehörenden Befehle FSAVE und FRESTORE erlauben das 
Ablegen von internen FPU-Zuständen im Speicher (als sogenannten State Frames) und auch 
das spätere Wiederherstellen des alten Zustands. In Multitasking-Systemen werden solche 
Befehle angewendet, um zwischen verschiedenen Tasks hin- und herzuschalten. Damit ist es 
dann möglich, den FPU-internen Status zwischenzeitlich zu sichern, einen anderen Task zu 
bearbeiten und anschließend den ersten Task mit dem originalen FPU-Status wiederherzustel¬ 
len und weiterzuführen! 
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Das Floating Point Control Register (FPCR) 

Dieses 32 Bit-Register verwendet zur Zeit nur die beiden niederwertigsten Bytes. Es kann vom 
Benutzer gelesen und beschrieben werden (z. B. durch FMOVE.L FPCR.dO). 

Das Exception Enable byte ( ENABLE ) (Bits 8.. 15 des FPCR) erlaubt die Freigabe (Bit gesetzt) 
und das Sperren (Bit gelöscht) von verschiedenen Exceptions, die durch die FPU veranlaßt 
werden können. 


15 

14 

13 

12 

11 

10 

9 

8 

BSUN 

SNAN 

OPERR 

OVFL 

UNFL 

DZ 

INEX2 



- Unexakte Dezima¬ 
le Eingabe 
Unexakte Operation 
Division durch 0 
Underflow 

- Overflow 

Operand fehlerhaft 
Signaling Not a 
Number 

- Branch/Set on 

Unordered 


Im Mode Control Byte {MODE) (Bits 0..7 des FPCR) kann der Anwender bestimmte Modali¬ 
täten für den Rundungsprozeß einstellen. 


7 6 5 4 3 2 1 0 


Präzision 


Modus 


Null 


Durch die beiden Modus-Bits wird festgelegt, wie ungenaue Resultate gerundet werden sollen. 
(Es läßt sich nicht jede Dezimalzahl exakt als Binärzahl mit einer festen Stellenzahl darstel¬ 
len). 

0 0 Der nächstliegende, darstellbare Wert wird genommen. Sollten sich zwei Werte anbie¬ 
ten, die beide gleich “nahe” liegen, so wird der Wert mit dem niedrigstwertigen Bit=0 
genommen! 
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0 1 Als Round-to-zero bezeichnet. Effekt ist der, daß die Bits rechts der Rundungsstelle 
gelöscht werden! 

1 0 Es wird zum nächstliegenden Wert in Richtung gerundet. 

1 1 Rundung auf den nächstliegenden Wert in Richtung +°°. 

Die beiden Präzisionbits spezifizieren, wo der Rundungspunkt der Mantisse liegen soll. 

0 0 Extended Precision. Es wird auf eine 64-Bit-Mantisse gerundet. 

0 1 Single Precision. Rundung auf eine 24-Bit-Mantisse. 

1 0 Double Precision. 53-Bit-Mantisse für die Rundung vorsehen. 

1 1 RFFU (Soll heißen: Reserved for future use!) 

Das Floating Point Status Register (FPSR) 

Alle vier Bytes dieses 32-Bit-Registers werden verwendet. Lesen und Beschreiben des Regi¬ 
sters durch den Anwender ist möglich (z.B. durch FMOVE.L dO,FPSR). 

Das höchstwertige Byte (Bits 24..31) wird als Floating Point Condition Code Byte ( FPCC) 
bezeichnet und signalisiert in 4 Bits den Bedingungscode einer mathematischen Operation, 
bei dem ein FP-Datenregister beteiligt war. Wichtig dabei ist, daß die Bedingungscodes nicht 
von der ausgeführten Operation abhängig sind, sondern von dem sich als Resultat ergebenden 
Datentyp! 


31 30 29 

28 

27 

26 

25 

24 

Null 

N 

Z 

I 

NAN 


N Negatives Resultat (Negative-Bit) 

Z Ergebnis ist Null (Zero-Bit) 

I Resultat ist +/- Unendlich (Infinity-Bit) 

NAN Ergebnis ist keine gültige Zahl oder Unordered (= bei der ausgeführten Operation war 

mindestens ein Eingabe-Operand ein NAN!) 

Die Bits 16.. 23 des FPSR bilden das Quotient Byte. Es wird am Ende einer FMOD oderFREM- 
Operation entsprechend gesetzt. 
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Dabei enthält es in den niedrigstwertigen 7 Bits die 7 untersten Bits des Quotienten und im 
höchstwertigen Bit dessen Vorzeichen. 


23 22 21 20 19 18 17 16 


7 niedrigstwertige Bits des Quotienten 


H 


Vorzeichen des Quotienten 


Das Exception Status Byte ( EXC ) ist in den Bits 8.. 15 des FPSR enthalten. Es enthält je ein 
Bit für die acht möglichen Ausnahmebedingungen (Exceptions), die durch eine der letzten 
ausgeführten FPU-Operationen aufgetreten sind. Vor dem Start der meisten FPU-Operationen 
wird dieses Bit gelöscht, so daß ein Exception-Handler erkennen kann, welche Fließkomma- 
Operation(en) zur Ausnahmebehandlung führten. 


15 

14 

13 

12 

11 

10 

9 

8 

BSUN 

SNAN 

OPERJR 

OVFL 

UNFL 

DZ 

INEX2 

INEXI 


1 ..r."". "“tt Unexakte Dezima¬ 

le Eingabe 

-Unexakte Operation 

- Division durch 0 

-—-- Underflow 

-—-—- Overflow 

-Operand fehlerhaft 

-Signaling Not a 

Number 

.-. . Branch/Set on 

Unordered 

Die Bitanordnung stimmt dabei mit dem ENABLE-Byte des Floating Point Control Registers 
(FPCR) überein. Auch wenn die Exception durch das korrespondierende Bit im ENABLE- 
Byte gesperrt sein sollte, so wird doch das Exception-Status-Bit bei Auftreten einer entspre¬ 
chenden Ausnahmebedingung gesetzt! 

Für den Fall, daß ohne Ausnahmeverarbeitung gearbeitet wird, existiert das Accrued 
Exception Byte ( AEXC ) in den Bits 0..7 des FPSR. In diesem Register werden alle Floating- 
Point Exceptions, die nach dem letzten Löschen des Registers (muß der User allerdings selbst 
veranlassen!) im Laufe der letzten ausgeführten Operationen aufgetreten sind, “zusammen¬ 
gesammelt”. 
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Das erspart dem User das Überprüfen des EXC-Bytes nach jeder Fließkommaoperation! Es 
reicht dann aus, am Ende einer Serie von Fließkommaoperationen nachzuschauen, ob zwi¬ 
schenzeitlich eine Ausnahmebedingung aufgetreten ist. 


7 

6 

5 

4 

3 

2 1 0 

IOP 

OVFL 

UNFL 

DZ 

INEX 

Null 


Unexakte dezimale Eingabe 
Division durch Null 
Underflow 
Overflow 

Unzulässige Operation 


Das Floating Point Instruction Address Register 
(FPIAR) 


Da ja bei der Zusammenarbeit zwischen CPU und FPU zum großen Teil Prozesse “nebenein¬ 
ander” herlaufen, ist es erforderlich festzuhalten, bei welchem Befehl (Adresse) die FPU denn 
gerade ist. Sonst könnte bei einer FPU-Exception die CPU (und damit der Exception-Handler) 
nicht so einfach feststellen, bei welchem FPU-Befehl die Ausnahmebedingung auftrat. 

Im FPIAR wird deshalb jeweils die Adresse des augenblicklich zu bearbeitenden FPU-Befehls 
vor seiner Ausführung abgelegt. 
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Kapitel 3: ROM und RAM beim TT 

Viel Platz für das Betriebssystem - Das TT-ROM 

Die im TT zusätzlich hinzugekommene Hardware braucht natürlich entsprechende Unterstüt¬ 
zung durch Betriebssystem-Software. So kommt denn ATARI im TT (und STE) auch nicht 
mehr mit den im ST noch ausreichenden 192 KByte ROM aus.Verwendet werden nun 
1 MBit-EPROM-Chips, wobei das Platinenlayout im TT (und STE) entsprechend flexibel 
gestaltet wurde. So können sowohl EPROMs des Typs 27256,27512,27C1000,270001 und 
270010 verwendet werden. Es lassen sich aber auch 1-MBit-ROMs verwenden. Von der 
Zugriffsgeschwindigkeit reichen 150 ns-Typen wohl aus. 

Beim TT sind vier (beim STE sind es 2!) 32polige Sockel für die Betriebssystem-Chips 
vorgesehen. Damit ist es im TT also möglich, 512 KByte-Sytemsoftware unterzubringen. In 
der Tat sind auch alle vier Sockel mit Megabit-Eproms bestückt. Was aber noch längst nicht 
heißt, daß diese auch in ihrer Kapazität voll ausgereizt wurden. Es ist wohl eher so, daß man 
so gerade über die 256 KByte-Grenze “gerutscht” ist (TOS 3.01 und 3.05 sind ca. $41000 = 
266240 Bytes lang). Es sind aber auf jeden Fall alle vier Sockel mit Chips zu bestücken, da 
ja im TT ein 32-Bit-Datenbus verwendet wird. Jeder Chip bedient also ein Viertel des Daten¬ 
busses. 

Das Betriebssystem-ROM erscheint im TT an zwei Stellen des CPU-Adreßraums. Zum einen 
ist es so ziemlich am oberen Ende des “ST- Adreßraums” (die unteren 16 MByte, die von einer 
68000er-CPU adressiert werden können!) von $E0 0000.. $EF FFFF zu “finden”. Dafür sorgt 
die MMU in der 68030-CPU. Eigentlich liegt der ROM-Bereich am hinteren Ende des 
68030er-Speicherbereichs bei $FFE0 0000 .. $FFEF FFFF! 

Auch beim TT findet man wieder in den ersten beiden Langwörtem des Speicherraums die 
Startwerte für die CPU (Adresse $0 = Startwert für den Supervisor Stackpointer; Adresse $4 
= Startwert für den Programmzähler). Diese 8 Bytes werden, wie beim ST(E) aus dem Be¬ 
triebssystem-ROM ($FFEOOOOO. ,$FFE0 0007) durch entsprechende Adreßdekodierung 
dort eingeblendet. 

RAM ist nicht gleich RAM! - Der TT kennt 
mindestens zwei “Sorten” 

Um dem TT zeitgemäße Leistungsfähigkeit zukommen zu lassen, wurde es erforderlich, den 
beim ST(E) doch eher eingeschränkten Speicherraum von max. 12 MByte (ab $C0 0000 hat 
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Abb. 3.1: Die Einbindung der ROMs beim TT 






















ROM und RAM beim TT 


1039 


ATARI ja den Speicherbereich für eigene Anwendungen wie z. B. Grafikkarten reserviert!) 
entsprechend erweitern zu können. Vor allen Dingen, wo man doch eine CPU einsetzt, die im¬ 
merhin 4 GByte (!) direkt ansprechen kann, mußte man nach Lösungsmöglichkeiten suchen, 
wie man diesen Adreßraum nutzbar machen konnte, ohne gleichzeitig die Kompatibilität zu 
den ST(E)-Geräten zu verlieren. 

Die Lösung meint man mit dem sogenannten “Altemate RAM” gefunden zu haben. So 
existiert dann zusätzlich zum ST-kompatiblen RAM, in dem sich neben der CPU auch noch 
der DMA-Baustein für ACSI-Datentransfers und der Videocontroller die Zugriffe auf das vor¬ 
handene RAM teilen, noch eine zweite Sorte RAM, die nur durch die CPU angesprochen wer¬ 
den kann. Wobei das mit dem “nur durch die CPU ansprechbar” nicht immer ganz korrekt ist. 
Lediglich das Altemate-RAM, welches überden VME-Busanschluß an den TT angeschlossen 
werden kann, und das RAM in dem Uhrenchip des TT können nur durch die CPU angesprochen 
werden. 

Das sogenannte Fast-RAM hingegen kann sowohl von der CPU als auch von den beiden DMA- 
Bausteinen für den SCSI-Bus und den schnellen seriellen Schnittstellen-Controller (SCC) 
benutzt werden. Allerdings kann der Videocontroller nicht an dieses Altemate-RAM und fällt 
somit als “Bremse” bei Fast-RAM-Zugriffen aus! 


ST-kompatibles RAM 

Im TT hat sich ATARI den Adreßraum von $8 .. $9F FFFF (mit einer weiteren “Option” für 
den Bereich von $A0 0000.. $DF FFFF) explizitals “dual purpose”-RAM reserviert. Dieses 
RAM wird (zeitlich) abwechselnd von der CPU und dem Videocontroller (deswegen wohl 
“dual purpose”!) benutzt. Dabei kann der Zugriff auf dieses RAM in minimal 250ns- 
Abständen zwischen den beiden Konkurrenten wechseln. Während eines laufenden Display- 
Zyklusses wird der Videocontroller natürlich nicht einfach unterbrochen, sondern die CPU 
bekommt die nächstmöglichen 250ns “zugewiesen”. 

Auf der Hauptplatine des TTs findet sich bereits standardmäßig 2 MByte ST-RAM. Aufge¬ 
baut ist dieses aus 16 DRAMs der Organisation 256Kx4Bit! Es werden dabei 100ns- 
DRAMs verwendet. Soweit gibt es bisher keine wesentlichen Unterschiede zum RAM in 
ST(E)s. 

Aber nun zur Abweichung! Diese 16 RAM-Chips werden zu einem 64 Bit-Memory- 
Datenbus zusammengeschaltet! Dadurch ist es dem Videocontroller möglich, mit einem 
RAM-Zugriff sofort 8 Bytes an Bildschirmdaten auszulesen! Die Anpassung des 64 Bit-Me- 
mory-Datenbusses an den im System ansonsten verwendeten 32 Bit-Datenbus übernehmen 
zwei Spezialchips (als FUNNEL = Trichter bezeichnet). 
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Abb. 3.2: Aufbau der ST-RAM-Erweiterungskarte (rechter Teil) 
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Natürlich ist es vorgesehen, dieses “dual purpose”-RAM zu erweitern. Auf der Hauptplatine 
(unter der Harddisk) befinden sich dazu zwei 96polige Federleisten nach DIN 41 612 (oder 
VG 95 324, deshalb auch häufig als VG-Leisten bezeichnet). 

Es reicht aber nun nicht aus, einfach dort eine Platine mit nur den RAMs einzusetzen. Vielmehr 
benötigen diese RAMs eine eigene MCU (Memory Control Unit). Die MCU auf der TT- 
Hauptplatine hat genug mit dem dort untergebrachten RAM zu tun. Deshalb sind auch alle für 
eine MCU erforderlichen Signale auf diese beiden VG-Leisten geführt. ATARI hat dabei 
allerdings eine Signalaufteilung für diese beiden Leisten vorgenommen. 

Die mit der Bezeichnung J501 versehene VG-Leiste auf der TT-Hauptplatine stellt dabei die 
64 Leitungen für den Memory-Datenbus und die Versorgungsspannungsanschlüsse zur 
Verfügung (dieser Steckanschluß findet sein “Gegenstück” in dem Anschluß J1 der ST-RAM- 
Erweiterungssplatine in der Abbildung 3.2). Über die VG-Leiste J502 werden der 32 Bit- 
Adreßbus und die Signale für die MCU (plus Versorgungsanschlüsse) geliefert. 

Außerdem werden noch die Busleitungen D0..D10 des 32 Bit-Datenbusses zur MCU der 
Erweiterungsplatine geführt (irgendwie müssen ja auch die Register in der MCU gesetzt 
werden können!). Auf der Erweiterungsplatine ist dieser Anschluß mit J2 bezeichnet! 

Die MCU hat natürlich nicht nur die Aufgabe, für einen gemultiplexten Adreßbus zu den 
RAMs und die dazu gehörenden RAS- und CAS-Signale zu sorgen. Da ja DMA-Betrieb 
genauso möglich sein muß, ist in der MCU die entsprechende Logik untergebracht! 

Gleiches gilt für Zugriffe des Videocontrollers. Also sind die dazu erforderlichen Signale 
ebenfalls zur MCU auf der Erweiterungskarte geführt. 

Im Moment verwendet ATARI für seine RAM-Erweitemngskarten noch 16 DRAMs der 
Organisation 256K x 4 Bit und kommt so aufeine Kapazität von 2 MByte auf der Erweiterungs¬ 
karte. 

Sobald aber 4 MBit-Chips in entsprechenden Stückzahlen erhältlich sind, wird die Erweiterungs¬ 
karte dann 8 MByte Kapazität umfassen können. Die MCU weist bereits den entsprechenden 
Anschluß für die gemultiplexte Adreßleitung 9 (MAD9) auf! 


TT-spezifisches RAM - Das Fast-RAM 

Den Spitznamen “Fast-RAM” hat diese Sorte RAM im TT wohl wegen seiner nahezu aus¬ 
schließlichen Nutzung durch die CPU bekommen. ATARI spricht aus diesem Grunde in 
seinen Dokumentationen deshalb auch vom “single purpose”-RAM. 
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Es ist als Erweiterung zum (ST)-RAM auf der Hauptplatine vorgesehen. Standardmäßigfindet 
sich auf demTT-Motherboard also kein Fast-RAM, sondern lediglich eine Anschlußmöglichkeit 
für eine entsprechende Erweiterungskarte. 

Da der Videocontroller auf dieses RAM nicht zugreifen kann, entfällt auch die Notwendigkeit, 
es in Form eines 64 Bit breiten Datenbusses anzulegen. So findet man denn beim Erweite¬ 
rungssteckplatz auch nur einen 32 Bit-Datenbus, mit direktem “Draht” (Busverbindung) zur 
CPU und FPU. Ähnlich wie bei der Erweiterung des ST-RAMs benötigt man auch für das Fast- 
RAM eine eigene FAST-MCU auf der Erweiterungskarte. Da aber keine Videocontroller¬ 
zugriffe in diesen Typ RAM vorgesehen sind, brauchen auch natürlich nicht so viele Steuer- 
und Meldeleitungen zur TTFMCU (TT-FAST-RAM-Memory Controller Unit) geführt zu 
werden. 

ATARI verwendet im Moment auf seinen Erweiterungskarten vier SIM-Module der Organi¬ 
sation 1M x 8 Bit und kommt damit auf eine Kapazität von 4 MByte für diese Karte. Sobald 
aber die 4M x 8 Bit in größeren (und preiswerteren) Stückzahlen erhältlich sind, wird es auch 
eine 16 MByte-Karte für die Fast-RAM-Erweiterung geben. Ob dazu allerdings die gleiche 
TTFMCU verwendet werden kann, konnte von ATARI-Deutschland noch nicht bestätigt 
werden (die gemultiplexte Adreßbusleihing MAD10 ist zumindest schon mal vorhanden!). 

Um die Cache-Speicher der MC68030 besonders effektiv zu füllen (im sogenannten Burst- 
fill-Modus lassen sich bis zu vier Langwörter mit sehr wenigen Taktzyklen unmittelbar hinter¬ 
einander einiesen!), werden für das Fast-RAM Bausteine verwendet, die im Nibble-Mode 
arbeiten. Damit ist es möglich, nach einem Zugriff mittels normaler RAS/CAS-Adressierung 
(erst Zeilenadresse, dann Spaltenadresse an die RAMs legen und jeweils durch RAS- bzw. 
CAS-Signal (aktiv Low) die Zelladresse im RAM-Chip auswählen) nur durch Ausgabe 
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weiterer C AS-Impulse Zugriff auf die drei folgenden Adressen zu erhalten. Das spart natürlich 
einiges an Zeit und erhöht somit den Datendurchsatz. 

Auf der FAST-RAM-Erweiterungsplatine läßt sich durch Jumper außerdem einstellen, wo die 
Startadresse des FAST-RAM liegen soll. Ebenfalls läßt sich über einen Jumper der Burst-fill- 
Modus wahlweise abschalten (die Standardeinstellung ist natürlich mit Burst-fill-Modus!). 


Der Cartridgeport beim TT 

ATARI hat beim TT auch den Anschluß für ROM-Cartridges beibehalten. Dieser ist bis auf 
weiteres kompatibel zum ST(E)-Cartridge-Anschluß. Also keine Erweiterung des 128 KByte- 
Adreßraums am Cartridge-Port, Allerdings finden sich die 128 KByte des Cartridges zum 
einen im ST-Adreßraum an gewohnter Stelle (bei $FA 0000.. $FB FFFF) als auch am oberen 
Ende des 32 Bit-Adreßraums bei $FFFA 0000..$FFFB FFFF! 

Die Behandlung der Cartridge-Software funktioniert weiterhin wie bereits beim ST erläutert. 

Ein Unterschied besteht jedoch in bezug auf das Timing. Da der TT-Cartridge-Anschluß sich 
in einer 16 MHz-Umgebung befindet, werden manche Dongles mit speziellen Zugriffsmecha¬ 
nismen evtl. Probleme mit dem etwas anderen Timing haben. Das liegt unter anderem daran, 
daß jetzt nicht mehr die_UDS- und JLDS-Signale (Upper Data Strobe und Lower Data Strobe) 
für den Cartridgeport von der CPU erzeugt werden, sondern von der MCU nachgebildet wer¬ 
den. Die MC68030-CPU mit ihren 32 Bit Busbreite benutzt für die Signalisierung, welche 
Datenbusbreite sie beim laufenden Buszyklus verwenden will, ja die Signale SIZ0 und SIZ1 
sowie _DS ACK0 und_DSACKl! 

Außerdem hat ATARI einen kleinen Schritt in Richtung Sicherheit gemacht und die +5V- 
Leitung zum Cartridge-Port im TT über eine Sicherung (0,5 A) geführt. 

Seinen ursprünglichen Zweck, nämlich das Bereitstellen von Software auf ROM-Modulen, 
erfüllt der TT-Cartridgeport jedoch ohne weitere Modifikationen bei bereits bestehenden 
Modulen. Schnellere ROMs bzw. EPROMs als am ST(E) sind am TT-Cartridgeport also nicht 
erforderlich! 

Soviel zu ROM und RAM im TT. Das Altemate-RAM im Uhrenchip wird bei der Besprechung 
des MC146818 (so heißt der Uhrenchip im TT!) mit angesprochen. 
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Kapitel 4: Der Videocontroller im TT 


ATARI hat dem TT zusätzlich zu den schon vom ST(E) her bekannten Grafikbetriebsarten 
einige TT-spezifische Modi eingebaut. Insgesamt sechs verschiedene Bildschirmauflösungen 
sind beim TT nun möglich. Insbesondere für die TT-spezifischen Auflösungen, bei denen der 
Bildschirmspeicher nahezu die fünffache Größe gegenüber dem ST-Bildschirmspeicher auf¬ 
weist, ist natürlich eine entsprechend schnelle Videohardware erforderlich. 

In der höchsten Auflösung werden 1280 x 960 Bildpunkte in Monochrom dargestellt. Das 
Ganze funktioniert dank einer hohen Vertikalen Ablenkfrequenz von 71 Hz auch noch flim- 
merfrei! Bei so hohen Pixeltakten greift ATARI dann aber auch auf bewährte Spezialchips für 
den Taktoszillator und das Shiftregister zurück (National Semiconductor Chip-Set mit 
DP8530 und DP8516). Die Horizontale Ablenkfrequenz liegt in dieser Betriebsart dann bei 
ca. 74 kHz! Für die anderen Modi verwendet ATARI “hausgemachte” Videohardware, wie 
schon bei der ST(E)-Serie, 


Der Videoanschluß 

Beim TT ist ATARI von den Spezialsteckverbindem der ST(E)-Serie abgegangen und 
verwendet nun gleiche Steckverbinder wie beim “Industriestandard”. So findet sich für den 
Monitoranschluß denn auch eine 15polige Subminiatur-D Buchse mit “kleinem” Kontaktab¬ 
stand. Die Belegung dieser Buchse ist in Abbildung 4.1 dargestellt. 
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Da aber die TT-Hoch-Auflösung ebenfalls über diese Buchse geführt ist, kann man bei der 
Belegung nicht von einer Kompatibilität zum “Industriestandard” sprechen. Allerdings lassen 
sich handelsübliche V GA-Monitore in den ersten fünf Auflösungen am TT betreiben. Das liegt 
daran, daß ATARI im TT bei einer Vertikal-Ablenkfrequenz von 60 Hz bleibt (auch bei der 
ST-Hoch-Auflösung! Also aus ist’s mit der Flimmerfreiheit in ST-Hoch am IT!). 

Die horizontale Ablenkfrequenz liegt bei ca. 32 kHz in den unteren fünf Auflösungen. 

Für die Signalpegel der drei Farbsignalausgänge und die Synchronsignale gilt das gleiche, wie 
bereits beim ST(E) gesagt. R-, G- und B-Anschluß liefern an einer Last von 750 eine 
Signalamplitude von 1 Vss. Die V- und H-Synchronimpulse liegen im TTL-Pegel vor und sind 
Low-Aktiv! 

Warum ATARI allerdings nur ca. 75% der horizontalen Breite einer Zeile nutzt, ist mir nicht 
klar. So könnte man doch immerhin statt der momentanen max. 640 Pixel pro Zeile “locker” 
auf über 800 bis 900 Pixel pro Zeile kommen. 


Die ST-Betriebsmodi 

Die Organisation des Bildspeichers in den ST-Auflösungen ist die gleiche, wie bereits für den 
ST(E) beschrieben. Auch hier wird wieder mit Bitplanes gearbeitet. In allen drei ST-Modi ist 
die Größe des Bildschirmspeichers 32000 Byte! 


ST-High-Resolution 

Im ST-Monochrombetrieb wird der gesamte Bildschirmspeicher als eine Bitplane aufgefaßt. 
Je 40 Words entsprechen einer Bildschirmzeile. 

Das erste Word im Bildschirmspeicher ist dabei in der ersten Bildschirmzeile für die ganz links 
stehenden 16 Bits zuständig. Siehe hierzu auch Abbildung 2.6 im ST-Hardwareteil “Das 
Grafiksystem”. 

Das höchstwertige Bit jedes Words ist dem ganz links liegenden Pixel der 16 durch dieses 
Word gesteuerten Bildpunkte zugeordnet. 

ATARI bezeichnet diesen Modus auch als Duochrom-Modus! Es können nämlich nicht nur 
die ZuständeSchwarz und Weiß dargestellt, sondern zwei Farben aus der 256 Register umfas¬ 
senden TT-Palette für Vorder- und Hintergrund benutzt werden. Verwendet werden immer 
die beiden Farben aus den beiden letzten TT-Farbpaletten-Registem (Nr. 254 und Nr. 255). 
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ST >Medium-Resolution 

Hiermit können je Zeile 640 Bildpunkte angesteuert werden. In vertikaler Richtung werden 
200 Zeilen geschrieben, was bei vielen grafischen Abbildungen zu “verzerrten” Proportionen 
führt. Die Farbe eines Pixels kann aus einem von den ersten vier Farbpalettenregistem 
ausgewählt werden. Jedes Palettenregister bietet die Möglichkeit, 4096 Farben einzustellen. 
Die Organisation der Farbbits der drei Primärfarben ist dabei die gleiche wie beim STE. 

Diese Colorbetriebsart arbeitet mit zwei wortweise ineinander verzahnten Bitplanes. Je zwei 
“übereinander” liegende Bits dieser Planes bilden einen Indexwert für das auszuwählende 
Farbregister. Dieses Farbregister enthält dann je 4 Bits für die drei Primärfarben Rot, Grün und 
Blau. Die Pixelfarbe wird also indirekt über den Indexwert aus je 2 Bits der beiden Bitplanes 
abgeleitet. Siehe hierzu auch Abbildung 2.7 im ST-Hardwareteil “Das Grafiksystem”. Eine 
Bildschirmzeile besteht in dieser Betriebsart aus zweimal 40 Wörtern zu 16 Bits! 


ST-Low-Resolution 

Das Darstellungformat umfaßt 320 (hör.) x 200 (vert.) Bildpunkte. Jedes Pixel kann von seiner 
Farbe her aus einem von 16 Farbpalettenregistem ausgewählt werden. Auch hier läßt sich in 
jedem Farbpalettenregister eine von 4096 Farben einstellen. 

Es wird mit vier wortweise ineinander verzahnten Bitplanes gearbeitet. Je vier “übereinander” 
liegende Bits bilden dann den Indexwert für das zu selektierende Palettenregister mit der 
Pixelfarbinformation. Eine Bildschirmzeile besteht aus viermal 20 Wörtern zu je 16 Bits! Sie¬ 
he auch Abbildung 2.8 im ST-Hardwareteil “Das Grafiksystem”. 


Die TT-Grafik-Betriebsarten 

Die Video-Hardware des TT bietet noch weitere drei Auflösungen, Bis auf die TT-High- 
Auflösung lassen sich auch diese Darstellungsmodi auf dem gleichen Monitor wie die ST- 
Modi abbilden. In allen drei TT-Modi ist die Größe des Bildschirmspeichers ebenfalls wieder 
gleich. Sie beträgt nämlich genau 153600 Byte! 


TT-Low-Resolution 

Diese Betriebsart bildet 320 Pixel je Zeile bei 480 Zeilen pro Bild ab. Dabei läßt sich die Farbe 
eines Pixel aus einem von 256 (!) Farbpalettenregistem auswählen. Jedes Palettenregister 
kann eine von 4096 möglichen Farbeinstellungen aufweisen. 
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Um aus 256 Palette-Registern auswählen zu können, sind 8 Bits zur Indexbildung erforder¬ 
lich. Deshalb wird in dieser Auflösung mit acht wortweise ineinander verschachtelten Bit¬ 
planes gearbeitet. Eine Bildschirmzeile ist damit 320 Pixel/ 16 (Bits pro Wort) x acht (Planes) 
= 160 Words “lang”. Bei 480 Zeilen pro Bild ergibt das einen Bildschirmspeicher der Größe 
von 153600 Bytes (WZBW = Was Zu Beweisen War). 



Abb. 4.2: Die Organisation des Bildschirmspeichers in TT-Low 


TT-Medium-Resolution 

Es werden je Zeile 640 Pixel dargestellt. In vertikaler Richtung werden 480 Zeilen geschrie¬ 
ben. Je Pixel kann aus einem der unteren 16 Farbpalettenregister der Wert für die Pixelfarbe 
(1 aus 4096 Farbeinstellungen je Palettenregister möglich) entnommen werden. 
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Da nur aus den ersten 16 Palettenregistem der 256 möglichen ausgewählt wird, sind auch nur 
vier Bits (= Planes) zur Bildung der Palettenreg.-Nummer erforderlich. Diese vier Bitplanes 
sind ebenfalls wortweise ineinander verzahnt, wie in der Abbildung 4.3 dargestellt. 

Eine Bildschirmzeile belegt im Bildschirmspeicher 4 x 640/16 = 160 Words (= 320 Bytes). 








imxR 




Kjoj 


! 


2 2 

,1! E31 



Bit plane S 


Bit plane X 


Bit plane 2 


Bit plane 3 


Farbreaister 


-*►! 


Bitkonbination selek¬ 
tiert eines der 16 
Farbregister 


x~ 

7 

Register 0 

X 

Register 1 

X 

| 

i 

Register 14 

5 

| Register 15 

t 


Registerinh, 

bestinnt 

Pixelfarbe 


Abb. 4.3: Die Organisation des Bildschirmspeichers bei TT-Medium 


TT-High-Resolution 

Genau schon wie beim ST(E) die High-'Resolution benötigt auch diese hochauflösende Bild¬ 
schirmdarstellung beim TT einen speziellen Monitor. 

Hier wird mit hohen Ablenkfrequenzen von 71 Hz für die Vertikalfrequenz und ca. 74 kHz 
für die Horizontalfrequenz gearbeitet. Zum einen soll ein ruhiges Bild für die Augen erzielt 
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werden (hohe V-Frequenz), und zum anderen soll eine große Menge an Zeilen (hohe H- 
Frequenz) auf dem Schirm dargestellt werden. Das fuhrt aber ebenfalls mit den geforderten 
1280 Pixeln/Zeile zu hohen Pixeltakten. 

Im günstigsten Fall (ohne vordere und hintere Schwarzschulter einer Zeile = linker und rechter 
Rand einer Bildschirmzeile, der schwarz geschaltet wird, um Zeilenrückläufe unsichtbar zu 
machen, und ohne Zeilensynchronimpulse zu berücksichtigen) sind dabei Pixeltakte von 1280 
x 74 kHz = 95 MHz zu erwarten! 

Dafür braucht man zum einen schon hochwertige Monitore mit entsprechenden Bandbreiten 
im Videoteil und schnellen Strahlablenksystemen für die hohen Ablenkfrequenzen. 

Zum anderen ist der Videocontroller natürlich ebenfalls auf solche Anforderungen hin auszu¬ 
legen. Atari hat dabei allerdings nicht auf “Hausgemachtes” zurückgegriffen, sondern einen 
bewährten Chipsatz (Oszillator und Shifter) von National Semiconductor eingesetzt. 

Unter anderem kann man diese Pixelinformation auch nicht mehr in TTL-Technik ausgeben, 
sondern verwendet spezielle differentielle Ausgangstreiberstufen in ECL-Technik (Emitter 
Coupled Logic) dazu. 



Abb. 4.4: Die Organisation des Bildschirmspeichers in TT-High 
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Der Bildschirmspeicher, mit seinen auch hier 153600 Bytes, wird als eine Bitplane interpre¬ 
tiert. Jedes Bit repräsentiert also ein Pixel. Pro Bildschirmzeile werden 80 Words zur Darstel¬ 
lung der Pixelinformation verwendet. 


Die Programmierung der Video-Hardware 

Auch bei der Video-Hardware im TT hat ATARI versucht, möglichst viele Funktionen in 
möglichst wenigen Bausteinen zu integrieren. So reduziert sich die Hardware für alle Betriebs¬ 
arten mit 60 Hz V- und 32 kHz H-Frequenz (also ohne die TT-High-Auflösung) auf einen 
Chip. Allerdings sind auch im TT wieder einige Funktionen der Video-Hardware in andere 
Custom-Chips ausgelagert worden. 

Die Umsetzung der Bildspeicherdaten in Bildinformationen übernimmt der TT-SHIFTER. 
Dort sind die Schieberegister untergebracht, die die Bildschirmspeicherbits nach dem paral¬ 
lelen Laden über den Datenbus mit MCU- und FUNNEL-Hilfe seriell als Bildinformations¬ 
signal ausgeben. (FUNNEL = Trichter; diese Spezial-Chips setzen den 64 Bit breiten ST- 
RAM-Datenbus für den “Rest des TTs” auf 32 Bit um und erlauben der Videohardware einen 
Zugriff auf immer 64 Bits auf einmal!) 

Der Video-Adress-Counter und das Video-Base-Register sind allerdings in der MCU zu 
finden. Da bei einer ST-RAM-Erweiterungnoch eine zweite MCU auf der Erweiterungsplatine 
vorhanden ist, findet man auch dort ebenfalls diese Video-Register! 

Die Digital/Analog-Wandler für die Umsetzung der digitalen Farbintensitätsinformation in 
ein analoges Intensitätssignal für jede Primärfarbe sind im TT-SHIFTER untergebracht. Für 
das Timing bekommt der TT-SHIFTER einen 32-MHz-Takt eingespeist, aus dem er dann die 
erforderlichen Synchronsignale erzeugt. Außerdem liefert der TT-SHIFTER, aus dem 32- 
MHz-Mastertakt abgeleitet, Takte von 16 MHz für den Rest des Systems, einen 4-MHz-Takt 
für die beiden MFPs und einen 2-MHz-Takt für z. B. den Sound-Chip und den DMA-Sound- 
SHIFTER. Des weiteren kommen vom TT-SHIFTER die H- und V-Synchronsignale und das 
Display-Enable-Signal! 

Die Einbindung der Video-Hardware beim TT zeigt die Abbildung 4.5. 


Die Video-Hardware-Register im TT 

Aus Kompatibilitätsgründen zum ST(E) findet man für die drei ST-Auflösungen die zugehö¬ 
rigen Hardware-Register an der gleichen Stelle (Adresse) wie beim ST(E)! Zusätzlich kann 
man aber auch am obersten Ende des MC68030er-Adreßraums darauf zugreifen. 
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Abb. 4.5: Schaltungsauszug mit der TT-Video-Hardware 
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Video-Base-Register 

Der Anfang des Bildschirmspeichers für alle Betriebsmodi wird der Video-Hardware über das 
Video-Base-Register mitgeteilt. 


Adresse 

Modus 

Funktion 

Label 

$(FF)FF 8201 

RAV 

Video-Base-Reg. High-Byte 

“dbaseh” 

$(FF)FF 8203 

RAV 

Video-Base-Reg. Medium-Byte 

“dbasel” 

$(FF)FF 820D 

RAV 

Video-Base-Reg. Low-Byte 

“dbaselow” 


Beim Low-Byte der Video-Base-Adresse (“dbaselow” an Adr. $(FF)FF 820C) haben die Bits 
0. .2 keine Funktion, sprich: sie werden immer als 0 angenommen. Damit kann der Bildschirm¬ 
speicher im ST-RAM immer nur an einer 8-Byte-Schwelle liegen. Die Video-Hardware 
bearbeitet ja bei einem Speicherzugriff auch immer 64 Bits (8 Byte) auf einmal! 


Video-Address-Counter 

Die in diese drei Register einzuschreibende 24 Bit-Adresse wird bei jedem neuen Bildbeginn 
in den Video-Adress-Counterijibcxtittgisn. Dort wird sie dann laufend hochgezählt, bis das Bild 
fertig aufgebaut ist. 


Adresse 

Modus 

Funktion 

Label 

$(FF)FF 8205 

R 

Video-Address-Counter 

High-Byte 

“vcounthi" 

$(FF)FF 8207 

R 

Video-Address-Counter 

Medium-Byte 

“vcountmid” 

$(FF)FF 8209 

R 

Video-Address-Counter 

Low-Byte 

“vcountlow” 


Im Gegensatz zum STE können diese Register nur gelesen werden. Also keine großartigen 
Tricks mit “changing Video-Counter-Register on the fly!” für Display-Manipulationen wäh¬ 
rend des Bildaufbaus möglich! 


Sync-Mode-Register 

Aus Kompatibilitätsgründen zum ST existiert dann noch das ST-Sync-Mode-Register, das sich 
aber gar nicht kompatibel zum ST(E) verhält. 
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Adresse 

Modus 

Funktion 

Label 

$(FF)FF 820A 

R/W 

ST-Sync-Mode-Register 

“syncmode” 


In diesem Register hat nur das Bit 0 überhaupt eine Funktion. Beim ST wurde dort durch 
Setzen des Bits 0 auf externe Synchronisation des STs umgeschaltet. Beim TT ist es genau 
umgekehrt. Wenn das Bit 0 gesetzt ist, erhält man ein Bild, sonst werden die Synchronsignale 
abgeschaltet! 

ST-Farbregister 

Aus Kompatibilitätsgründen existieren im TT an gewohnter Stelle wie im ST(E) die 
16 Palettenregister zur Auswahl der Pixelfarbe. Die Bitbelegung für die drei Primärfarben ist 
die gleiche wie beim STE. Die unteren drei Bits jedes Nibbles weisen von rechts nach links 
steigende Wertigkeiten für den Intensitätswert auf. Allerdings hat dann das höchstwertige Bit 
eines Nibbles bei der Festlegung der Farbintensität die geringste Gewichtung (kompatibel zu 
STE-Palettenregistem)! DienachfolgendeTabellezeigtdieAdreßlageder 16 STE-kompatiblen 
Palettenregister im TT und ihre Bitbelegung. 


Adresse 

Modus 

Bitbelegung 

Label 

$(FF)FF 8240 

R/W 

XXXXrRRR gGGGbBBB 

“colorO” 

$(FF)FF 8242 

R/W 

XXXX rRRR gGGG bBBB 

“colorl” 

$(FF)FF 825C 

R/W 

XXXX rRRR gGGG bBBB 

“colorl4” 

$(FF)FF 825E 

R/W 

XXXX rRRR gGGG bBBB 

“colorl 5*’ 


Anmerkung-. Bitpositionen mit Kleinbuchstaben weisen auf das niedrigstwertige Farbwertbit 
hin! 

Diese 16 ST(E)-Palettenregister sind jedoch nicht separat von den 256 TT-Farbregistem zu 
sehen, sondern stellen vielmehr ein Subset der TT-Farbregister dar. Durch die vier untersten 
Bits im TT-Shift-Mode-Register wird nämlich festgelegt, welche 16er-Registergruppe der 
256 TT-Farbregister an den Adressen der ST-Farbregister auftaucht. 


ST-Shift-Mode-Register 

Ebenfalls aus Kompatibilitätsgründen existiert an (vom ST(E) her) gewohnter Adresse das 
ST-Shift-Mode-Register. 
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Hieriiberwird die gewünschte Betriebsart für den TT-SHIFTER programmiert. Die Bitbelegung 
ist kompatibel zum ST(E), 


Adresse 

Modus 

Funktion 

Label 

$(FF)FF 8260 

R/W 

ST-Shift-Mode-Register 

“shiftmd” 


xxxx xxMM xxxx xxxx (Word) 


00 
0 1 
10 
1 1 


ST-Low (320 x 200, 4 Planes) 
ST-Mid (640 x 200, 2 Planes) 
ST-High (640 x 400, 1 Plane) 
<Reserviert> 


Allerdings tauchen bei Verwendung der TT-spezifischen Betriebsmodi deren Einstellungen 
ebenfalls in diesem Shift-Mode-Register auf! Das gilt sowohl für die Modus-Bits als auch für 
die Palettenbank. Man findet also die im TT-Shift-Mode-Register eingestellten Werte eben¬ 
falls im ST-Shift-Mode-Register wieder! 


TT-Shift-Mode-Register 

Sowohl die ST-Grafikmodi als auch die speziellen TT-Betriebsarten lassen sich in diesem TT- 
eigenen Register einstellen. Die Bitbelegung ist die gleiche wie im ST-Shift-Mode-Register, 
nur daß halt noch ein paar Steuerbits hinzugekommen sind! 


Adresse 

Modus 

Funktion 

Label 

$(FF)FF 8262 

RAV 

TT-Shift-Mode-Register 

“shift_TT” 


SxxHxMMM 


xxxx PPPP (Word) 

I 1 _Registerbank für 


ST-Palette 


000 ST-Low ( 320 x 200,4 Planes) 
0 0 1 ST-Mid (640 x 200, 2 Planes) 

0 1 0 ST-High (640 x 400, 1 Plane) 

0 1 1 <Reserviert> 

1 0 0 TT-Mid (640 x 480,4 Planes) 

10 1 <Reserviert> 

1 1 0 TT-High (1280 x 960,1 Plane) 

1 1 1 TT-Low ( 320 x 480, 8 Planes) 

- Hyper-Mono-Modus 

Sample & Hold-Mode 
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Mit den untersten vier B its dieses Registers wird festgelegt, welcher Registersatz der 256 TT - 
Palette-Register für die 16 ST(E)-kompatiblen Farbpalettenregister verwendet wird. Ein 
Wert von Null wählt also die TT-Farbregister 0..15 für die ST(E)-Farbregister aus! Durch 
Ändern dieser vier Bits lassen sich alle 16 ST(E)-Farbregister “auf einen Schlag” verändern! 

Mit Setzen von Bit 12 in diesem Register wird der Hyper-Mono-Modus eingeschaltet. Damit 
läßt sich der TT-SH1FTER auf einen speziellen Monochrom-Modus mit 256 Graustufen pro¬ 
grammieren. Dabei werden im TT-SHIFTER die D/A-Wandler für den Grün- und Blau-Kanal 
zusammengefaßt. Dazu sind acht Intensitätsbits nötig. Die vier höchstwertigen Intensitäts¬ 
bits kommen vom Grün-Kanal, das niederwertige Nibble aus den Palettenbits des Blau-Ka¬ 
nals. 

Das Sample & Hold-Bit sorgt dafür, daß so eine Art Schmiereffekt auf dem Bildschirm erzielt 
wird. Anstelle der Hintergrundfarbe (Farbe 0) wird die zuletzt benutzte Farbe weiterverwen¬ 
det. Einfach mal ausprobieren! 


Die TT-Palette-Register 

Diese 256 Farbregister können alle einzeln angesprochen und geändert werden. Jedoch nur 
die TT-Low-Betriebsart verwendet auch alle 256 Register bei der Darstellung. Die 
256 Farbregister sind in 16 "Banks” zu je 16 Registern aufgeteilt, von denen dann immereine 
Bank als ST-Farbregistersatz verwendet wird. Welche Bank das ist, wird mit den vier untersten 
Bits im TT-Shift-Mode-Register eingestellt. 

Die Farbintensität kann mit jeweils vier Bits für jede der drei Primärfarben eingestellt werden. 
Dabei hat ATARI die Gewichtung der Bits aber wieder in eine vernünftigere Form gebracht 
(also nicht mehr Least significant Bit ganz links im Nibble wie im STE, sondern LSB ganz 
rechts und MSB ganz links im Nibble!). Da ja die TT-Palette-Register auch für die ST(E)- 
Palette-Register benutzt werden, muß diese unterschiedliche Behandlung der Intensitäts¬ 
steuerung angepaßt werden. Das geschieht aber hardwaremäßig. Die Beziehung “Höchstwertiges 
Bit im STE-Farbnibble wird niedrigstwertiges Bit im TT-Farbnibble” und umgekehrt ist be¬ 
reits per Hardware realisiert! 


Adresse 

Modus 

Bitbelegung 

Label 

$(FF)FF 8400 

RAV 

XXXX RRRr GGGg BBBb 

“TT_col0” 

$(FF)FF 8402 

RAV 

XXXXRRRr GGGg BBBb 

“TT_coll” 

$(FF)FF 85FC 

RAV 

XXXX RRRr GGGg BBBb 

“TT_col254” 

$(FF)FF 85FE 

RAV 

XXXX RRRr GGGg BBBb 

“TT_col255” 
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Betriebssystemunterstützung der Video-Hardware 

Alle diese neuen Möglichkeiten der Videohardware wollen und sollen natürlich möglichst 
einfach und standardisiert genutzt sein. Deshalb hat ATARI eine Menge neuer XBIOS- 
Aufrufe im TT-TOS eingebaut, um dem Programmierer das direkte Manipulieren der 
Hardware-Register nach Möglichkeit zu ersparen. 

Im Kapitel zum XBIOS sind diese neuen Aufrufe mit entsprechender Beschreibung zu finden. 
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Kapitel 5: Und weil’s so schön war - 
Noch’n MFPim TT 


Da ja im TT einiges an Hardware zusätzlich vorhanden ist, unter anderem eben auch zusätz¬ 
liche serielle Schnittstellen, hat ATARI zur Unterstützung einen weiteren MFP-Baustein 
(MC68901) spendiert. 


Der ST-MFP im TT 

Der “alte" MFP im TT hat die gleichen Aufgaben wie im ST(E) übernommen und verhält sich 
auch kompatibel dazu. Das heißt unter anderem auch, daß durch die gleichen DMA-Sound- 
Fähigkeiten, wie schon im STE, eine “Doppelbelegung” des Portanschlusses 107 vorgenom¬ 
men wurde. Es werden ja darüber sowohl die Monochrom-Detect-Leitung des Monitors als 
auch das DMA-Sound-Aktiv-Signal abgefragt. Näheres dazu kann man im Anhang “Die 
Hardware des STE” nachschlagen. Auch beim TT gibt’s natürlich das Monochrom-Detect- 
Signal, welches hier vom Pin 9 der Monitorbuchse stammt und mit dem DMA-Sound-Aktiv- 
Signal ver”Exklusiv Oder”t wird. 

Da es beim TT allerdings keinen BLUTER gibt, ist die sonst an 103 angeschlossene 
Interruptleitung des BLITTERs hier nicht vorhanden. ATARI hat dafür diesen Anschluß mit 
einem Signal CLKDIR (Clock Direction ???) belegt, dessen Bedeutung nicht unmittelbar aus 
der Schaltung ersichtlich ist. Es scheint aber in Verbindung mit dem Netzwerkinterface des 
TT zu stehen. Ich könnte mir vorstellen, daß man diesen Port als Ausgang benutzt, um damit 
(über ein PAL) dem SCC-Baustein auf Kanal A einen TT-intemen Takt aufzuschalten. 

Die Bezeichnung des Seriellen Ports, der mit dem ST-MFP realisiert und zum ST(E) 
kompatibel ist, lautet auf “Serial Port C” bzw. “MODEM 1” und ist auf eine 9polige Sub-D- 
Buchse zusammengeschrumpft. Auch hier ist wieder (wie beim ST(E» der Soundchip bei den 
Handshakesignalen (RTS und DTR) beteiligt! Also alles beim alten geblieben. 


Der “neue” MFP im TT 

Durch den Einsatz von neuen DMA-fähigen Schnittstellen im TT, wie den SCSI-Port und die 
zwei seriellen Schnittstellen über den SCC (Serial Communications Controller vom Typ 
Z85C30), benötigt man natürlich entsprechende Meldeeingänge, um z. B. den Abschluß von 
DMA-Operationen signalisiert zu bekommen. 
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Also hat inan einen zweiten MFP-Baustein verwendet, bei dem zusätzlich zu den interruptfähigen 
Eingangsports noch eine serielle Schnittstelle als “Abfallprodukt” herausschaute (wird als 
SERIAL 1 bezeichnet). Diese serielle Schnittstelle verfügt jedoch über keinerlei Steuer- und 
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Abb. 5.1: Einbindung der beiden MFPs in die TT-Hardware 
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Meldeleitungen! Lediglich Empfangs- und Sendedatenleitung stehen zur Verfügung. Dieser 
zweite MFP (in Zukunft als TT-MFP bezeichnet) liegt schaltungsmäßig “parallel” zum bereits 
vorhandenen MFP. Diese Parallelschaltung bezieht sich jedoch nur auf die Anbindung zum 
Daten- und Adreßbus und die erforderlichen Leitungen zum Control-Bus. Allerdings gibt’s 
schon noch kleine Abweichungen. Die Abbildung 5.1 zeigt die Einbindung der beiden MFP- 
Chips in das Hardwarekonzept des TT. 

Die Chip-Select-Leitung ist bei den beiden MFPs natürlich nicht die gleiche, sondern der TT - 
MFPhatsichnurim AdreßbereichSFF FA81.. $FFFAAF(bzw. $FFFF FA81.. $FFFF FAAF) 
zu melden. Dabei liegen auch hier die Register (je 8 Bit breit!) des Bausteins auf ungeraden 
Adressen. Die Reihenfolge und Funktion der Register ist die gleiche wie beim ST-MFP, mit 
folgenden Ausnahmen: 

Adresse Zugriff Funktion des Registers Label 

$FF FA81 R/W GPIP-Data-Register (GPIP) “GPIP TT” 

Es handelt sich zwar um ein I/O-Register, jedoch initialisiert das 
gegenwärtige TOS im TT alle TT-MFP-I/O-Ports als Eingänge. 
Man kann also über dieses Register die Zustände der MFP-Ports 
IO0..IO7 auslesen. Wenn man einzelne Ports auf Ausgang 
schalten will (insbesondere bei IOO und IO 1 interessant, da diese 
auf Pfostenfeldleisten (J602 auf dem Motherboard) geführt 
sind),muß man entsprechend dieBitsOund 1 imData-Direction- 
Register setzen! Durch Beschreiben des GPIP_TT-Registers 
werden die als Ausgänge programmierten Ports entsprechend 
gesetzt oder rückgesetzt. 

Bit 0 und 1 signalisieren den Zustand der Anschlüsse IOO und 
IOl. Diese sind auf dem TT-Motherboard auf Pfostensteck¬ 
verbinder (J602) geführt und können für künftige Hardware¬ 
erweiterungen verwendet werden. Da die I/O-Ports des MFP 
sowohl als Ein- oder Ausgang programmiert werden können, 
läßt sich damit evtl, einiges anfangen. 

Bit 2 ist das Interrupt-Request-Signal vom SCC-DMA-Bau- 
stein. Mit einem Low meldet damit der SCC-DMA-Kanal das 
Ende einer DMA-Operation. 

Bit 3 gibt die Möglichkeit, das “Ring indicator”-Signal von der 
Buchse MODEM 2 auszuwerten. Mit einem Low wird hier das 
Setzen dieser Schnittstellenleitung signalisiert. 
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Adresse Zugriff Funktion des Registers Label 


Bit 4 kommtvonPin34deseingebautenFloppy-Disk-Laufwerks. 
Über diesen Anschluß zeigt die Floppy ihren Betriebszustand an. 
Manche Floppies liefern hier auch eine Information über einen 
Medien Wechsel. Dieses Bit wird vom Betriebssystem aber nicht 
benutzt. 

Bit 5 wird vom SCSI-DMA-Controller beeinflußt, der bei Auf¬ 
treten eines Busfehlers während des DMA-Prozesses diesen 
Anschluß auf Low setzt. 

Bit 6 ist ein Interrupt-Request (Low-aktiv) vom TT-Uhrenchip. 
Wann der Uhrenchip z. B. einen Interrupt auslösen kann, sollte 
man in dem entsprechenden Kapitel über den RTC 146818 
nachlesen. 

Bit 7 geht auf High (!), wenn der SCSI-Controller-Chip des TT 
(Typ 5380) einen Interrupt auslöst! Sowohl das TOS als auch 
Harddisktreiber verwenden dieses Bit (allerdings nur im Polling- 
Verfahren), um festzustellen, ob die gewünschte SCSI-Operati- 
on beendet wurde. Also hat es eine ähnliche Funktion wie das Bit 
5 beim ST-MFP für die Fertigmeldung von FDC/ACSI-Bus! 

$FF FA83 RAV Active-Edge-Register (AER) “AER TT” 

Für jedes Bit des I/O-Ports läßt sich hier einstellen, bei welchem 
Flankenwechsel an einem Port ein Interrupt ausgelöst werden 
soll (wenn er denn über das Interrupt-Enable-Register einge¬ 
schaltet ist!). 

Ein gesetztes Bit veranlaßt eine Interrupt-Anforderung bei Low- 
>High-Übergang am entsprechenden Portanschluß. Wann bei 
einem gelöschten Bit unterbrochen wird, können Sie sich jetzt, 
glaube ich, selbst denken! 

$FF FA85 R/W Data-Direction-Register (DDR) “DDRTT” 

Für jeden I/O-Portanschluß existiert ein Bit. Bei gesetztem Bit 
ist der entsprechende Port als Ausgang programmiert. Bei 
gelöschtem Bit fungiert der zugehörige Port als Eingang. (Das 
TT-TOS setzt im Moment alle Ports als Eingänge!) 
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Die Timer des TT-MFP 

Die Funktionsweise der Timer kann im Kapitel über den MFP im ST nachgeschlagen werden. 
Es sollen hier und auf der folgenden Seite nur kurz die Unterschiede aufgezeigt werden. 

- Der Timer-A-Eingang liegt fest auf Masse. Damit fallen also die Betriebsart Pulsbreiten¬ 
messung (wen interessiert schon die Zeitdauer eines immer anliegenden Low-Signals?) 
und die Ereigniszählung (es ereignet sich halt wenig auf dem Massepotential) als Anwen¬ 
dung weg! 

Bliebe also nur noch der Delay Mode übrig. Vom TOS wird der Timer A jedoch nicht 
benutzt! 

- Der Timer-B-Eingang liegt zusammen mit dem gleichen Eingang des ST-MFP am 
Display-Enable-Signal. Damit kann also bei Bedarf mit diesem Timer ebenfalls ein 
Zähler für Bildschirmzeilen realisiert werden. 


Die Adressen der Timer-Register beim TT-MFP: 

Adresse Modus Belegung Funktion Label 


$FF FA99 

R7W 

—-RCCCC 

Timer-A-Control-Reg. (‘TACR TT’) 

$FF FA9B 

R/W 

-RCCCC 

Timer-B-Control-Reg. (‘TBCR TT’) 




1 1 II 

Modus 

Vorteiler 




0000 

Stop 

- 




0001 

Delay 

1 : 4 




0010 

Delay 

1 : 10 




0011 

Delay 

1 : 16 




0100 

Delay 

1 : 50 




0101 

Delay 

1 : 64 




0110 

Delay 

1 : 100 




0111 

Delay 

1 :200 




1000 

Ereignis 

- 




1001 

Pulsbreite 

1 : 4 




1010 

Pulsbreite 

1 : 10 




1011 

Pulsbreite 

1 : 16 




1100 

Pulsbreite 

1 : 50 




1101 

Pulsbreite 

1 : 64 




1110 

Pulsbreite 

1 : 100 




1111 

Pulsbreite 

1 :200 





Timer A- bzw. B-Ausgang auf Low 
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Adresse Modus Belegung Funktion Label 


$FF FA9D R/W -CCC-DDD Timer C+D Control Reg. (‘TCDCRTT’) 

(C: Takt für SCC-Channel 2) 

(D: Baudrate für SERIAL 1) 




IN II ! 

Modus 

Vorteiler 




000-000 

STOP 

- 




001-001 

Delay 

1 : 4 




010-010 

Delay 

1 : 10 




011-011 

Delay 

1 : 16 




100-100 

Delay 

1 : 50 




101-101 

Delay 

1 : 64 




110-110 

Delay 

1 : 100 




111-111 

Delay 

1:200 



Timer: 

(C> (D) 




$FF FA9F 

RAV 

DDDDDDDD 

Timer-A-Data-Register 

(‘TADR TT’) 

$FF FAA1 

R/W 

DDDDDDDD 

Timer-B-Data-Register 

(‘TBDR TT’) 

$FF FAA3 

R/W 

DDDDDDDD 

Timer-C-Data-Register 

(‘TCDR TT’) 

$FF FAA5 

R/W 

DDDDDDDD 

Timer-D-Data-Register 

(‘TDDR TT’) 


Weitere Unterschiede: 


Timer-C des TT-MFP kann als Taktgenerator für den Kanal B des neuen SCC-Chips 
verwendet werden. Das TOS stellt im Timer-C des TT-MFP eine Frequenz von ca. 
12,5 kHz am Timerausgang ein (Timer-C mit l:4-Vorteiler und Timer-C-Data-Wert 
von 25!). Der Kanal B des SCC kann allerdings mit unterschiedlichen Taktraten für 
Sende- und Empfangsrichtung betrieben werden. Mehr dazu bei der Beschreibung des 
SCC! 

- Genau wie beim ST-MFP kann der Timer D des TT-MFP als Baudratengenerator für den 

seriellen Port des MFP verwendet werden. Da der zugrundeliegende Takt für den TT- 
MFP der gleiche ist wie beim ST-MFP, kann man auch hier Baudraten bis 19200 Bd 
einstellen. 


Interrupts durch den TT-MFP 

Der MFP kann ja ebenfalls als Interruptquelle in einem Mikrocomputersystem auftreten (siehe 
dazu auch die Erläuterungen zu den MFP-Interrupts des STs!). Diese Möglichkeit wollte sich 
ATARI beim TT natürlich für den TT-MFP ebenfalls offenhalten. So sind denn im TT beide 
MFPs, was die Interruptbehandlung angeht, “hintereinander gekettet”. Für diese Verkettung 
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besitzt der MFP die Anschlüsse _IEI und _IEO. Eine Interruptanforderung stellt der MFP mit 
einem Low-Signal auf dem _IRQ-Anschluß (Interrupt Request). Diesbezüglich sind die 
beiden MFPs parallelgeschaltet. D. h., der MFP, der einen Interrupt anfordert, zieht die JRQ- 
Leitung auf Low. Daran erkennt dieTTSCU (TT-System Control Unit) eine MFP-Interrupt- 
anforderung. 

Während des nun folgenden Interrupt-Bestätigungszyklusses, der durch die CPU durchgeführt 
wird, erhalten die JACK-Anschlüsse der beiden MFPs dieses Bestätigungssignal zugeführt. 
Welcher MFP nun “seinen” Interrupt bearbeitet bekommt (also höher priorisiert ist), wird 
durch dessen Position in der JEI -> JEO-Verkettung festgelegt. Nur jener MFP darf nun auf 
eine Interruptbestätigung reagieren, dessen JEI-Anschluß auf Low liegt. Als Folge davon 
setzt dieser MFP seinen JEO-Anschluß auf High, und der in der Kette dahinter angeschlosse¬ 
ne MFP hat sich aus dieser Interruptbestätigung herauszuhalten! 

Der Schaltungsauszug mit den beiden MFPs im TT zeigt für diese Verkettung nun an, daß der 
TT-MFP infolge seines immer aktivierten JEI-Anschlusses (fest auf Low gelegt!) höher 
priorisiert ist. Nur wenn vom TT-MFP keine Interruptanforderung vorliegt, wird bei einem 
InteiTuptbestätigungszyklus an dessen JEO-Ausgang ein Low liegen und damit dem ST-MFP 
die Möglichkeit gegeben, “seinen” Interrupt bearbeitet zu bekommen! 

Jeder MFP besitzt 16 Interruptkanäle, die untereinander unterschiedlich gewichtet sind. Alle 
acht I/O-Ports und die vier Timer kommen als mögliche Interruptquellen in Frage. Außerdem 
sind noch 4 Interruptquellen bei der seriellen Schnittstelle des MFP zu finden. Die Priorisierung 
der Interrupts ist bei jedem MFP gleich und kann deshalb im Kapitel “Der Multifunktionsbaustein 
MFP 68901” im Hardwareteil zum ST nachgeschlagen werden. 

Der MFP übergibt während des Interrupt-Bestätigungszyklusses der CPU eine eigene 8 Bit 
breite Vektomummer (Non-Autovektor-Interrupt Prinzip). Daraus kann die CPU dann, nach 
Multiplikation der Vektomummer mit 4, die Adresse des zugehörigen Interruptvektors im 
RAM ermitteln. Damit mehrere MFPs in einem System unterschiedliche Vektomummern er¬ 
zeugen können, ist das High-Nibble der MFP-Vektomummer im Interrupt-Vektor-Register 
eines MFPs einstellbar. Das Low-Nibble ergibt sich dann aus der Kanalnummer, welcher den 
Interrupt ausgelöst hat. 

Im TT sorgt das TOS durch Einstellen des Interrupt-Vektor-Registers im ST-MFP dafür, daß 
alle Vektomummern mit dem Nibble $4 beginnen und damit die zugehörigen Interruptvektoren 
ab Adresse $40 x 4 = $100 im RAM zu finden sind (wie auch beim ST(E)). Für den TT-MFP 
beginnen alle Vektomummern mit $5, und deshalb findet man die zugehörigen 16 Interrupt¬ 
vektoren unmittelbar anschließend an die ST-MFP-Interruptvektoren, ab Adresse $140 im 
Speicher. Die nachfolgende Abbildung zeigt noch mal kurz die Lage der TT-MFP-Interrupt- 
vektoren im RAM: 
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litt !arxm 
UEEnUm 


Kurzbeschreibg. der Interruptquelle 

MFP-Interrupt 

S140 

0 

Maskiert 

I/O-Pin 1, J602 auf Motherboard 

I/O-Port B (I0Ö3 

5144 

1 

naskiert 

I/O-Pin 3, J602 auf Motherboard 

I/O-Port 1 (1013 

$148 

2 

naskiert 

XDMAIRQ von SCC-DMA-ControlIer 

I/O-Port 2 (1023 

514C 

3 

naskiert 

XBRIRQ von RI-flnschluß, MODEM 2 

I/O-Port 3 (1033 

5150 

4 

naskiert 

Baudrate für SERIAL 1-Port 

Tiner D 

5154 

5 

naskiert 

TCCLK-Takt an SCC, Channel 2 

Tiner C 

5158 

6 

naskiert 

DCH (Drive ready) v. int. Floppy 

I/O—Port 4 (I043 

5150 

7 

naskiert 

XSDMAIRQ von SCSI-DMA-Control1er 

I/O-Port 5 (I053 

51GB 

8 

naskiert 

Di sdI ay-Enable-Signal 

Tiner B 

5164 

9 

aktiv. 

Sendefehler ser. Port des TT-MFP 

XMIT-Error 

51G8 

1B 

aktiu. 

Sendepuffer leer t " ) 

XMIT-Buf, enpty 

516C 

11 

aktiv. 

Enpfangsfehler ( ) 

RCU-Err-or 

5170 

12 

aktiv 

Enpfangspuff. voll C “ 1 

RCU-Buffer full 

5174 

13 

naskiert 

Nicht benutzt 

Tiner A 

5178 

14 

naskiert 

Interrupt von TT-Uhrenchip 

I/O-Port G (1063 

517C 

15 

naskiert 

Interrupt von SCSI-Chip "5380" 

I/O-Port 7 (1073 


Abb. 5.2: Die Lage der TT-MFP-Interruptvektoren im RAM 


Die Interrupt-Steuerregister des TT-MFP 

Die vier Register des TT-MFP, die zur Steuerung der Interruptbehandlung durch den MFP 
verwendet werden, sind natürlich vollkommen identisch zu denen des bereits vom ST her 
bekannten MFP. Lediglich die Interruptquellen sind bei den I/O-Ports andere Signale aus dem 
“Inneren” des TT. Da die Signalbelegung ja sowohl aus dem Schaltungsauszug als auch der 
Tabelle mit den Interruptvektoren hervorgeht, soll hier nur noch kurz auf diese MFP-Register 
eingegangen werden. Die Wirkungsweise der Bits dieser einzelnen Register kann (sinnge¬ 
mäß) in ausführlicher Form im Kapitel über den ST-MFP bei der ST-Hardware nachgelesen 
werden. 

Adresse Modus Belegung Funktion Label 


$FF FA87 R/W 


eeeEEEEe Interrupt-Enable-Reg. A (‘IERA-TT’) 



Timer B (Display enable Signal) 
XMIT Error (RS 232) 

XMIT Buffer empty (RS 232) 

RCV Error (RS 232) 

RCV Buffer full (RS 232) 

Timer A (nicht benutzt) 

Port 16 (TT-Uhrenchip-IRQ-Anschluß) 
Port 17 (IRQ von SCSI-Contr.-Chip) 
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Adresse Modus Belegung Funktion 

$FF FA89 R/W eeEeeeee Interrupt-Enable-Reg. B (‘IERB TT’) 

Port 10 (Pin 1 des J602-Steckers) 

Port II (Pin 3 des J602-Steckers) 

Port 12 (IRQ von SCC-DMA-Baustein) 

Port 13 (Ring indicator von MODEM 2) 

Timer D (Baudraten-Gen. SERIAL 1) 

Timer C (TCCLK an SCC-Channei 2) 

Port 14 (DCH-Signal v. P.34 int. Floppy) 

Port 15 (IRQ von SCSI-DMA-Baustein) 

SFFFA8B RAV PPPPPPPP Int.-Pending-Register A (‘IPRATT’) 

(Bitbelegung siehe ‘IERA_TT’) 

$FF FA8D RAV PPPPPPPP Int.-Pending-Register B (‘IPRBTT’) 

(Bitbelegung siehe iERB_TT’) 

$FF FA8F RAV SSSSSSSS Int.-In-Service-Register A (‘ISRA_TT’) 

(Bitbelegung siehe ‘IERA_TT’) 

$FF FA91 RAV SSSSSSSS Int.-In-Service-Register B (‘ISRBTT’) 

(Bitbelegung siehe ‘IERB_TT’) 

$FF FA93 R/W mmmMMMfai Interrupt-Mask-Register A (‘IMRATT’) 

(Bitbelegung siehe ‘IERA_TT’) 

$FF FA95 R/W mmnrn im mm m Interrupt-Mask-Register B FIMRBTT’) 

(Bitbelegung siehe ‘EERB_TT’) 

$FF FA97 RAV VWVS— - Interrupt-Vektor-Register (‘VR_TT’) 

I- End-of-Interrupt Modus 

-- High-Nibble der Vektomummer (=5) 


Anmerkung: Die vom TOS vorgenommenen Standardeinstellungen in den Interrupt-Enable- 
und Interrupt-Mask-Registem sind durch Klein- bzw. Großbuchstaben bei der 
jeweiligen Bitposition angegeben. Ein Großbuchstabe repräsentiert dabei ein 
gesetztes Bit! 



Label 
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Dieser Zusammenfassung kann man also entnehmen, daß nur die Interrupts für die serielle 
Schnittstelle des TT-MFP und den Timer-C “enabled” sind. Außerdem sind im Mask-Register 
alle Interrupts bis auf die der seriellen Schnittstelle ausmaskiert. Ähnlich ist es bei den zugehö¬ 
rigen Interrupt-Service-Routinen. Nur die als “Enabled” eingestellten Interrupts haben auch 
einen sinnvollen Interruptvektor. 

Auch der TT-MFP wird im Software-End-of-Interrupt-Modus betrieben. Das heißt, daß die 
zugehörige Interrupt-Service-Routine nach Abarbeitung das entsprechende Interrupt-In-Ser- 
vice-Bit zurücksetzen muß! 


Die Steuerregister für die serielle Schnittstelle 
des TT-MFP 


Die Funktion der Register für die serielle Schnittstelle SERIAL 1, die mit dem TT-MFP 
realisiert wird, ist schon beim ST-MFP erläutert worden. 

Deshalb hier nur eine kurze Registerübersicht mit den entsprechenden Adressen: 

Adresse Modus Belegung Funktion Label 


$FF FAA7 RAV 
$FF FAA9 RAV 


SSSSSSSS Sync.-Char. Register (‘SCR TT’) 
CCCCCCC- IJSART-Control-Register (‘UCR TT’) 

^-l=Even-, 0=Odd-Parity 

-Parity Enable 


I 1 

Start Stop 

Modus 

00 - 

— 0 

0 

Synchron 

01 - 

— 1 

1 

Asynchron 

10 — 

— 1 

1,5 

Asynchron 

11 - 

— 1 

2 

Asynchron 


Wortlänge 

in Bits 


00 - 8 

01 -- 7 

10 —- 6 

ll-5 


Clock Mode (lClk/16,0=Clk) 



Und weil’s so schön war-- Noch’n MFP im TT 
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Adresse Modus Belegung Funktion Label 

$FF FAAB R/W SSSSSSSS Receiver-Status-Register (‘RSR_TT’) 

Receiver Enable 
— Synchronous Strip Enable 

Match bzw. Character in progress 
Found/Search bzw. Break 

- Frame Error 

- Parity Error 

- Overrun Error 

--— Buffer Full 


$FF FAAD R/W SSSSSSSS Transmitter-Status-Register (‘TSRJTT’) 

~~ Transmitter Enable 

Sender-Ausgangsleitung 
00 — Hochohmig 
01 — Low-Pegel 

10 ~ High-Pegel 

11 — Schleife 

-— Break senden 

- Senden beendet 

L -- Auto Tumaround 

—- Underrun Error 

- Sendepuffer Leer 

Adresse Modus Belegung Funktion Label 

$FF FAAF R/W DDDDDDDD USART-Data-Register (‘UDRTT’) 

(Lesen holt Byte aus Empfangspuffer) 
(Schreiben bringt Byte in Sendepuffer) 


Alle Adreßangaben zu MFP-TT-Registem sind für den ST - Adreßraum gemacht. Die gleichen 
Register sind auch im oberen TT-Adreßraum unter $FFFF FA8X .. $FFFF FAFF erreichbar! 
Soviel zu den MFPs im TT! 





Kapitel 6: Ein Schritt in die richtige 
Richtung - Der TT-SCSI-Port 


1073 


Schon bei der ST(E)-Serie hat sich ATARI um eine Schnittstelle für schnelle Peripheriegeräte 
(Festplatten, Laserdrucker) eigene Gedanken gemacht. Herausgekommen ist dann dabei eine 
zu nichts (außer manchmal zu sich selbst) kompatible Schnittstelle, der ACSI-Bus. Dieser 
ähnelt in Ansätzen dem bei Kleincomputersystemen schon weit verbeiteten SCSI-Bus (Small 
Computer Systems /nterface). 

Beim TT hat man (= ATARI) sich dann wohl überlegt, daß man diese Performance-Bremse 
für Festplatten, den Plattencontroller bzw. beim Anschluß von SCSI-Platten, den als Interface 
erforderlichen Host-Adapter, besser weglassen sollte. Schließlich soll der TT ja auch mal ein 
“großes” Betriebssystem (UNIX) unterstützen, und dazu sind schnelle Massenspeicher natür¬ 
lich eine sehr wichtige Voraussetzung! Also findet sich im TT nun auch ein sehr bekannter 
SCSI-Controller-Chip(der5380),dervoneinemeigenenDMA-Controller beim Datentransfer 
unterstützt wird. Bevor hier auf die Interna (sprich: Register, deren Adressen und die Funktio¬ 
nen) des SCSI-und des DMA-Controllers eingegangen wird, erst mal ein Überblick über den 
SCSI-Bus. 


Der SCSI-Bus 

Es handelt sich hierbei um einen bidirektionalen 8-Bit-Bus, an dem bis zu acht Teilnehmer 
angeschlossen sein können. Von der SCSI-Bus-Spezifikation her sind diese Teilnehmer mit 
“Intelligenz” ausgestattet und können sowohl Computer als auch Controller zur Steuerung von 
Peripheriegeräten sein. Dabei können durchaus auch mehrere Computer am SCSI-Bus “hän¬ 
gen”. Ein Peripherie-Controller kann seinerseits nochmal bis zu acht Geräte bedienen (bei 
SCSI-Befehlen werden diese “Untergeräte” als “Logical Units” behandelt)! 

Vom Prinzip her kann jeder Busteilnehmer als Initiator oder als Target arbeiten. Die Funktion 
ist dabei die gleiche, wie schon beim ACSI-Bus beschrieben. Ein Initiator fordert von einem 
anderen Teilnehmer (dem Target) eine Reaktion an (in der Regel einen Datenaustausch). In 
der Praxis findet man jedoch Computer mit Host-Adaptern als Initiatoren und periphere Geräte 
wie Festplatten, Laserdrucker, CD-ROMs usw. als Targets. 


Damit es kein Durcheinander auf dem alle verbindenden Bus gibt, dürfen zur gleichen Zeit 
immer nur ein InitiatorundeinTarget miteinander kommunizieren. Der Informationsaustausch 
erfolgt asynchron mittels eines Request/Acknowledge-Protokolls. Es wird immer je ein Byte 
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übertragen und mittels des Handshakes bestätigt. (Es existiert allerdings eine Option für syn¬ 
chrone Transfers, die auch von einigen SCSI-Festplatten inzwischen unterstützt werden.) 
Außerdem haben alle angeschlossenen Busdevices eine eigene Priorität, welche über ein eige¬ 
nes Bit dargestellt wird. In einer sogenannten Arbitrations-Phase (Entscheidungsphase) prä¬ 
sentieren alle “Mitbewerber” um die Buszuteilung ihr Prioritätsbit (wegen der 8-Bit-Busbreite 
kann es also nur acht Geräte geben, die sich um die Buskontrolle streiten!). Das Device mit 
der höchsten Priorität “gewinnt” den Bus und kann seinerseits nun mit einem anderen Device 
in Verbindung treten. 


Die Busverbindung 

Verwendet wird zur Verbindung der einzelnen Bus-Teilnehmer (meistens) ein 50poliges 
Flachbandkabel mit entsprechendem Pfostenstecker. Jeweils gegenüberliegende Pins der 
Steckverbinder bilden dabei ein Pärchen (und damit auch die daran angeschlossenen Leitun¬ 
gen). Bis auf eine Ausnahme ist je eine Leitung eines solchen Adempaares bei der “single- 
ended-drivers”-Version als Masseleitung ausgeführt und dient somit als abschiranendes Ele¬ 
ment für die signalführende Leitung. 

Bis zu Leitungslängen von 6 m sieht der SCSI-Standard diese Ausführung als sogenannte 
“single-ended-drivers”-Version (eine Leitung liegt mit “einem Ende” fest auf Masse). Die 
“differential-dri vers”-Ausführung kommt mit ebenfalls 50 Leitungen aus, jedoch werden zu¬ 
sammengehörige Adempaare mit speziellen Differential-Treiberstufen angesteuert, um die 
Störsicherheit heraufzusetzen und längere Entfernungen (bis zu 25 m) zu überbrücken. 

Damit nicht der Eindruck entsteht, Atari mangele es an eigenen Ideen für Steckverbindern, 
hat man am TT den herausgeführten SCSI-Portanschluß auf einer “normalen” 25poligen Sub- 
D-Buchse enden lassen (das spart jede Masse Masse!). Dabei weist diese Belegung eine “ver¬ 
blüffende Ähnlichkeit” (sprich: Übereinstimmung) mit dem SCSI-Port bei MACINTOSH- 
Rechnem auf! 


Das Ende der Busverbindung 

An den beiden äußeren Enden einer Busverbindung wird der Bus durch Widerstandsnetzwerke 
abgeschlossen. Bei der (am häufigsten verwendeten) Single-ended-Driver-Version wird jede 
Signalleitung mit330 Q gegen Masse und 220 Q an +5 V abgeschlossen. Dafür verwendet man 
in der Regel Widerstandsnetzwerke in Steckfassungen, um bei Bedarf (wenn das Gerät z. B. 
nicht am Ende des Busses “hängt”) die Terminierung entfernen zu können. Optional existiert 
für diese Busterminierung eine eigene Terminator-Power-Leitung (kurz: Termpwr). Damit ist 
es möglich, alle Abschlußnetzwerke aus einer Quelle (+5V) zu speisen, unabhängig davon, 
ob die am Bus angeschlossenen Geräte eingeschaltet sind! 
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Die Signale auf dem SCSI-Bus 

Alle Signale auf dem Bus sind Low-aktiv! Die Belegung des SCSI-Bus-Anschlusses zeigt die 
Abbildung 6.1. Als Signalpegel werden TTL-Pegel verwendet. 


Steckverbinder 
an SCSI'Bus 



5 a 'i'O 


Belegung 

Ptn-Nr.: 

Belegung 

Data 0 

2 

1 

Masse 

Data 1 

4 

3 

Masse 

Data 2 

6 

5 

Masse 

Data 3 

8 

7 

Basse 

Data 4 

16 

9 

Masse 

Data 5 

12 

11 

Masse 

Data 6 

14 

13 

Masse 

Data 1 

16 

15 

Masse 

ParTly 

10 

i? 

Basse 

— 

20 

19 

Masse 

--- 

22 

21 

Masse 


24 

23 

Masse 

(Terupwr) 

26 

25 

H.C. 

— 

28 

27 

Masse 

— 

30 

29 

Masse 

RTH 

32 

31 

Basse 

— 

34 

33 

Basse 

BSV 

36 

36 

Masse 

RER 

38 

37 

Masse 

ResET 

48 

39 

Masse 

nsu 

42 

41 

Basse 

SEE 

44 

43 

Basse 

C/O 

46 

45 

Masse 

REO 

48 

47 

nasse 

ITH 

59 

49 

Masse 


fluflenansicht auf die 
SCSI“Buchse des TT 



1 - Htfi 

2 - HSG 

3 - 17Ö 

4 - RKET 

5 - BCK 

6 - BSY 

7 - Basse 
ß - Data 9 
9 - Basse 

10 - Data 3 

11 - Data 5 

12 - Data 6 

13 - Data 7 


14 - Masse 

15 - CTÖ 

16 - Masse 

17 - flTR 
1B - Basse 

19 - SEL 
28 - Pärity 

21 - Data 1 

22 - Data 2 

23 - Data 4 

24 - Basse 

25 - N.C. 


Abb . 6J: Die Belegung beim SCSI-Bus 


Ein Low an einem Ausgangsanschluß soll zwischen 0..0,4V liegen. Dabei muß ein Ausgang 
bei Low-Signal einen Strom von 48mA “verkraften” können! 

An einem Buseingang werden Spannungspegel bis 0,8V noch als Low “angesehen”. Die Last, 
mit der ein Eingang den Bus bei Low belastet, soll 0,4mA nicht überschreiten. 

High-Signale liegen zwischen 2,5V und 5,25V an Ausgangsanschlüssen. Bei Eingängen wer¬ 
den Signale zwischen 2V und 5,25 V als High angesehen. 

Eine Speisung für die Termpwr-Leitung soll bei einer Spannung zwischen 4V..5.25V einen 
Strom von 800mA liefern können. 
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Verwendete Leitungen 

Da im Prinzip alle Geräte sowohl auf den Bus ausgeben als auch von dort Daten aufnehmen 
können, empfiehlt sich für Ausgänge das Open-Collector-Prinzip. 

Reset (_RST) Pin 40 TT Pin 4 Bidirektional! 

Wenn dieses Signal gesetzt wird (auf Low geht), werden die laufenden Busaktivitäten beendet. 
Alle Teilnehmer werden in den Grundzustand zurückversetzt. 

Jeder Teilnehmer kann Reset auslösen. Die sogenannte “Reset hold time” (die Zeit, für die die 
_RST-Leitung mind. Low sein muß) beträgt 25ms. 

Busy(JBSY) Pin 36 TT Pin 6 Bidirektional! 

Der Bus ist schon abgefahren! Hiermit wird signalisiert, daß der Bus zur Zeit belegt ist. Auch 
während der Arbitration (Entscheidung, wer den Bus bekommt) geht Busy auf Low! 

Select (_SEL) Pin 44 TT Pin 19 Initiator -> Target 

Bei Reselect: Target -> Initiator 

Der Initiator signalisiert damit den Targets, doch bitte mal nachzusehen, ob sich nicht viel¬ 
leicht jemand durch die ebenfalls vom Initiator auf dem Datenbus ausgegebene Adresse (ID- 
Bit) angesprochen fühlen könnte (Targetauswahl). Ein Target benutzt dieses Signal, um sich 
in der Reselect-Phase wieder bei seinem Initiator zu melden (zum Beispiel eine Harddisk, die 
mit dem Formatieren fertig und nun bereit zu neuen Taten ist.) 

Attention (_ATN) Pin 32 TT Pin 17 Initiator -> Target 

Achtung! Der Initiator hat eine Message (Nachricht) für das Target. Da allerdings das Target 
bei Command-, Data-, Status- und Message-Transfers das “Heft in der Hand hält”, also den 
Bus steuert, fordert der Initiator mit diesem Signal eine “Message out’’-Phase beim Target an. 

Message (_MSG) Pin 42 TT Pin 2 Target -> Initiator 

Das Target signalisiert damit den Transfer einer Mitteilung (die Message-Richtung wird eben¬ 
falls vom Target bestimmt!) 

Control/Data (_C/D) Pin 46 TT Pin 15 Target-> Initiator 

Das Target bestimmt hiermit, ob es sich bei den Signalen auf dem Datenbus um Befehle, 
Statusinformationen oder Messages (Control-Informations) handelt (Low-Signal). 
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Während der eigentlichen Datenübertragungsphase (Data-Phase) liegt dann hier ein High- 
Signal. 


In-/Output (_I/0) Pin 50 TT Pin 3 Target -> Initiator 

Das Target gibt hierüber die Transportrichtung auf dem Datenbus bekannt (High: Initiator - 
> Target; Low: Target -> Initiator). 


Request (_REQ) Pin 48 TT Pin 1 Target -> Initiator 

Für den Handshake während des Informationsaustauschs über den Datenbus fordert das Target 
mit diesem Signal den Initiator auf, ein Datenbyte auf den Bus zu legen (Initiator -> Target) 
oder daß das Target ein Byte auf den Bus gelegt hat (Target -> Initiator). Die Transferrichtung 
wird ja durch das _I/0-Signal bestimmt! 


Acknwldg. (_ACK) Pin 38 TT Pin 5 Initiator -> Target 

Das Gegenstück zum JREQ-Signal. Hiermit bestätigt der Initiator, daß er das angeforderte 
Datenbyte auf den Datenbus gelegt (Initiator an Target) oder daß er das vom Target auf den 
Bus gelegte Byte eingelesen hat (Target an Initiator)! 

Datenbus (DB7..0) Pin 16, 14,12, 10, 8, 6,4, 2 

TT Pin 13, 12, 11, 23, 10, 22, 21, 8 Bidirektional 

Hierüber werden die Daten byteweise zwischen Target und Initiator verschoben. Die 
erreichbare Geschwindigkeit liegt laut “SCSI-Norm” bei max. 4 MByte/s. 

Parität (DP) Pin 18 TT Pin 20 Bidirektional 

Zusätzlich kann die Byteübertragung auf dem Bus mit einem ungeraden Paritätsbit gesichert 
werden. Wenn mit Parität gearbeitet wird, müssen auch alle angeschlossenen Devices diese 
Option verwenden. Beim TT wird diese Option z. Zt. nicht verwendet! 


Die Bus-Phasen 

Der Bus kann sich immer nur in einer von vier Hauptphasen befinden. Dabei werden diese 
Hauptphasen zum Teil noch in weitere Unterphasen unterschieden. 


Alle Phasen werden durch bestimmte Zustände der Signale Busy, Message, Select, Input/Out¬ 
put, Control/Data, Request und Acknowledge definiert. 
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BUS FREE 

Diese Phase ist dadurch charakterisiert, daß zur Zeit kein Gerät den Bus benutzt. Alle Bus¬ 
signale sind inaktiv. Erkennen kann man diese Phase daran, daß Busy und Select deaktiviert 
(= High) sind! 

Die angeschlossenen Geräte sollen alle Signale innerhalb des “Bus Clear Delay” (max. 800ns) 
deaktivieren, wenn nach Ablauf eines “Bus Settle Delay” (max. 400ns) Busy und Select auf 
High gegangen sind. 


ARBFTRATION 

Diese zweite Hauptphase ist nur dann anzutreffen, wenn ein System mit mehr als einem 
Initiator betrieben wird. Dann muß nämlich entschieden (to arbitrate = entscheiden) werden, 
welcher Initiator die Buskontrolle bekommt. Da die meisten Anwendungen beim TT z. Zt. 
noch der Betrieb von SCSI-Platten sind und der TT der einzige Initiator im System ist, hat man 
die Arbitration-Phase bei der zugehörigen Treibersoftware noch nicht implementiert. Der 
SCSI-Controller-Chip im TT ist dazu jedoch fähig! 

Wie bekommt nun ein Initiator die Kontrolle über den Bus? 

Warten, bis der Bus frei ist. Dazu müssen Busy und Select mindestens für die Dauer des 
Bus Settle Delay (400ns) deaktiviert sein. Danach ist für nochmal 800ns (“Bus Free 
Delay”) zu warten, bevor ein Device irgendein Signal setzen soll. 

- Der Initiator setzt Busy und aktiviert sein eigenes ID-Bit auf dem Datenbus (zieht die 
entsprechende Datenbusleitung auf Low!). 

- Nach Ablauf des “ Arbitration Delay” (2,2|lis) “untersucht” der Initiator den Datenbus auf 
höher priorisierte Initiatoren (DB0 ist niedrigste, DB7 höchste Prioritätsstufe). Wenn 
kein höher priorisiertes Gerät gefunden wurde, setzt der “Gewinner” die Select-Leitung 
auf Low. 

- Niedriger priorisierte Geräte haben ihr Busy-Signal und ihr ID-Bit innerhalb eines Bus 
Settle Delay (400ns) “vom Bus zu nehmen”, nachdem Select vom “Gewinner” aktiviert 
wurde. 

Bevor der “Gewinner” nach Setzen von Select weitere Signale auf den Bus legen darf (Eintritt 
in die folgende Selektions-Phase), hat er mindestens 400ns (Bus Settle Delay) plus 800ns (Bus 
Clear Delay) abzuwarten. 
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SELECTION 

Die dritte Hauptphase wird vom Initiator, der die Buskontrolle übernommen hat, verwendet, 
um das gewünschte Target zu adressieren. 

Um diese Phase von der RESELECTION-Phase (Wiederaufnahme einer Verbindung zwi¬ 
schen einem Target und “seinem” Initiator) zu unterscheiden, muß „I/O aktiviert sein! 

Der Initiator legt nun sein eigenes ID-Bit und das des Targets, mit dem zusammengearbeitet 
werden soll, auf den Datenbus. Nach 2 x 45ns (2 x Deskew Delay) aktiviert der Initiator das 
Busy-Signal. Weitere 400ns (Bus Settle Delay) später darf der Initiator dann mal schauen, ob 
denn ein Target reagiert hat. 

Das adressierte Target hat innerhalb der sogenannten “Selection Abort Time” (=200ns) zu 
reagieren, indem es nun seinerseits das Busy-Signal auf Low zieht. 

Innerhalb zwei Deskew Delays (2 x 45ns) nachdem der Initiator die Aktivierung von Busy 
durch das Target erkannt hat, wird vom Initiator die Select-Leitung deaktiviert. 

Wenn innerhalb von ca. 250ms nach Ausgabe der Targetadresse vom Initiator keine Reaktion 
vom Target kommt, wird eine Timeout-Prozedur eingeleitet. Dabei kann der Initiator dann 
z. B. ein Reset durch Setzen der _RST~Leitung starten. Die andere Möglichkeit besteht darin, 
nach Deaktivieren von Select wieder in die BUS FREE-Phase einzutreten. 


RESELECTION 

Bei dieser Phase geht die Initiative zur Herstellung einer Verbindung nicht vom Initiator, 
sondern vom Target aus. Diese Phase ist nur in Systemen mit ARBITRATION möglich. 

Dabei tauschen Target und Initiator eigentlich ihre Rollen. Das Target versucht während der 
ARBITRATION, den Bus zu übernehmen, und verfährt dabei genau wie dort bereits beschrie¬ 
ben. Wenn die Busübemahme geklappt hat, wird das Target die Select-Leitung aktivieren und, 
als Unterscheidung zur SELECTION, die RESELECTION durch Aktivierung von „I/O 
kenntlich machen. Außerdem gibt das Target dann das eigene ID-Bit und das des gewünschten 
Initiators auf den Bus. 

Zwei Deskew Delays (2 x 45ns) später deaktiviert das Target Busy und prüft nach weiteren 
400ns (Bus Settle delay) erstmalig den Bus auf eine Reaktion vom Initiator. Wenn der Initiator 
sich innerhalb von ca 250ms (=Selection Abort Time) meldet (=Busy aktiviert), übernimmt 
das Target selbst ebenfalls wieder mit Aktivierung von _BSY den Bus. Weitere 2 x 45ns (2 
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Deskew Delays) später wird vom Target Select deaktiviert. Danach steht wieder die 
Verbindung zwischen dem Initiator und dem Target, und das Target kann das Input/Output- 
Signal abschalten. 

Auch hierbei gibt es bei Überschreiten der Selection Abort Time (250ms) (wie bei der SE- 
LECTION-Phase) die Möglichkeit eines Bus Reset (allerdings diesmal vom Target veranlaßt) 
oder des Übergangs in die BUS F R EE-Phase. 


Systeme ohne ARBITRATION 

In Systemen ohne ARBITRATION/RESELECITON und mit nur einem Initiator (“Single 
Initiator Systems”, wie im Moment auch beim TT) steigt der Initiator nach der BUS FREE- 
Phase direkt in die SELECTION-Phase ein! 

Nach Feststellen von BUS FREE und Ablauf von 800ns (Bus Clear Delay) wird vom Initiator 
deshalb nur die gewünschte Target-SCSI-Adresse auf den Bus gesetzt und _SEL aktiviert. 
Wenn ein Target nur seine ID auf dem Bus findet und keine weitere (die des Initiators), geht 
es von einem “dummen” Initiator aus, der mit Meldungen nichts anfangen kann. 


Wenn die Verbindung steht - Die Transferphase 

Die vorher beschriebenen Phasen sind ja nur nötig, um die Verbindung zwischen zwei SCSI- 
Devices über den Bus herzustellen. Wenn das erfolgreich gelungen ist, können Befehle 
(COMMAND-Phase), Daten (DATA IN/OUT-Phase), Meldungen (MESSAGE-Phase) oder 
Zustandsinformationen (STATUS-Phase) ausgetauscht werden. Die komplette Steuemng des 
Austauschs liegt dabei jedoch beim Target! Dazu verwendet es die Signale _C/D, _I/0 und 
_MSG. Folgende Phasen können durch diese drei Signale unterschieden werden: 


MSG 

C/D 

I/O 

Phase 

Transferrichtung 

F 

F 

F 

DATA OUT 

Initiator an Target 

F 

F 

T 

DATA IN 

Target an Initiator 

F 

T 

F 

COMMAND 

Initiator an Target 

F 

T 

T 

STATUS 

Target an Initiator 

T 

F 

F 

Reserved 


T 

F 

T 

Reserved 


T 

T 

F 

MESSAGE OUT 

Initiator an Target 

T 

T 

T 

MESSAGE IN 

Target an Initiator 


F = False (High!); T = True (Low!) 
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Der Initiator kann lediglich über die Aktivierung von _ATN darauf aufmerksam machen, daß 
er eine Meldung abzusetzen hat. Das Target muß darauf dann entsprechend reagieren und in 
die MESSAGE OUT-Phase wechseln! 

Datenaustausch per Handshake 

Die Datenbytes werden per_REQ/_ACK-Handshake im Asynchronbetrieb (Standardbetriebs¬ 
weise) zwischen den beiden Geräten ausgetauscht. Jedes Byte erfordert einen _REQ/_ACK- 
Zyklus. Die Transferrichtung wird durch das _I/0-Signal festgelegt. 

Bei einem Transfer vom Target zum Initiator („I/O = Low!) legt das Target zunächst das zu 
übertragende Datenbyte auf den Bus (evtl, mit Paritätsbit auf der Paritäts-Leitung). Ein 
Deskew Delay (45ns) plus ein “Cable Skew Delay” (10ns) danach wird Request aktiviert. Der 
Initiator liest die Daten ein, sobald _REQ aktiviert wurde, und bestätigt die Übernahme der 
Daten durch Aktivierung von _ACK. Sobald das Target dieses bemerkt, kann es bereits wieder 
Änderungen auf dem Datenbus vornehmen (z. B. nächstes Byte anlegen) und _REQ wieder 
deaktivieren. Das sollte dann der Initiator auch schnellstens mitkriegen und als Reaktion 
darauf dann _ACK ebenfalls deaktivieren. Anschließend kann das Target wieder mit 
Aktivierung von _REQ das nächste Datenbyte ausgeben. 

Wenn Daten vom Initiator zumTarget übertragen werden sollen (_I/0=High!), gibt das Target 
den Wunsch nach einem neuen Datenbyte durch Aktivierung von _REQ bekannt. Der Initiator 
setzt die Datenbusleitungen auf den entsprechenden Wert und gibt nach einem Deskew Delay 
(45ns) plus dem Cable Skew Delay (10ns) die Gültigkeit der Daten auf dem Bus mit 
Aktivierung von _ACK bekannt. Sobald das Target das _ACK bemerkt, hat es die Daten 
einzulesen und als Quittung das Request-Signal zurückzunehmen. Wenn der Initiator dieses 
feststellt, hat er seinerseits „ACK zu deaktivieren und kann anschließend bereits neue Daten 
auf den Bus legen. Das Target holt sich diese dann mit dem nächsten _REQ wieder, wie bereits 
zuvor geschildert, ab. 

COMMAND-Phase 

Zunächst einmal sollte das Target natürlich erfahren, was der Initiator denn eigentlich will. 
Die Übermittlung der dazu erforderlichen Informationen geschieht in der COMMAND-Phase 
(dabei ist dann _C/D aktiviert!). Während dieser Phase sind „I/O und „MSG deaktiviert. Das 
Target holt sich per _REQ/_ACK-Handshake (wie schon zuvor beschrieben) den sogenannten 
“Command Deskriptor Block”, bestehend aus sechs, zehn oder zwölf Bytes, beim Initiator ab. 

An die COMMAND-Phase kann sich dann eine DATA IN- oder DATA OUT-Phase anschlie¬ 
ßen, während der Daten zwischen Initiator und Target ausgetauscht werden (z. B. bei SCSI- 
Platten am TT nahezu immer der Fall!). 
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DATA-Phasen 

Ob es sich um eine DATA IN- oder DATA OUT-Phase handelt, wird durch den Zustand der 
_l/0-Lcitung festgelegt (Low für DATA IN). Auch hier erfolgt der Datenaustausch wieder 
Byte für Byte (evtl, mit Paritätsbit) nach dem bereits beschriebenen _REQ/_ACK-Verfahren. 
Die _MSG- und _C/D-Leitung müssen dabei auf High gesetzt sein! 

STATUS-Phase 

Üblicherweise schließt die STATUS-Phase eine Initiator-Target-Kommunikation ab. Dabei 
wird an den Initiator ein Statusbyte übermittelt (also ist _I/0 = Low!), das es dem Initiator 
erlaubt, eine Aussage über den Zustand der beendeten Operation zu treffen. 

Auch diese Übermittlung erfolgt natürlich wieder gemäß dem JREQ/_ACK-Protokoll. Da es 
sich hierbei auch um eine Art Kontroll-Information handelt, ist während dieser Phase _C/D 
aktiviert. _MSG liegt auf High! 

Die Bedeutung des Statusbytes ist nachfolgend dargestellt; 


Status-Byte 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

Reserv, 

Herstellerspez. 

Status Byte Code 

Herst, spez. 


Hier nun die möglichen Rückmeldungen und deren Bedeutung im Statusbyte: 


Bits im Statusbyte 


7 

6 

5 

4 

3 

2 

1 

0 

Bedeutung 

R 

H 

H 

0 

0 

0 

0 

H 

GOOD 

R 

H 

H 

0 

0 

0 

1 

H 

CHECK CONDITION 

R 

H 

H 

0 

0 

1 

0 

H 

CONDITION MET/GOOD 

R 

H 

H 

0 

0 

1 

1 

H 

Reserviert 

R 

H 

H 

0 

1 

0 

0 

H 

BUSY 

R 

H 

H 

0 

1 

0 

1 

H 

Reserviert 

R 

H 

H 

0 

1 

1 

0 

H 

Reserviert 

R 

H 

H 

0 

1 

1 

1 

H 

Reserviert 
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7 

6 

5 

4 

3 

2 

1 

0 

Bedeutung 

R 

H 

H 

1 

0 

0 

0 

H 

INTERMEDIATE/GOOD 

R 

H 

H 

1 

0 

0 

1 

H 

Reserviert 

R 

H 

H 

1 

0 

1 

0 

H 

INTERMEDIATE/CONDITION 

MET/GOOD 

R 

H 

H 

1 

0 

1 

1 

H 

Reserviert 

R 

H 

H 

1 

1 

0 

0 

H 

RESERVATION CONFLICT 

R 

H 

H 

1 

1 

0 

1 

H 

Reserviert 

R 

H 

H 

1 

1 

1 

0 

H 

Reserviert 

R 

H 

H 

1 

1 

1 

1 

H 

Reserviert 


GOOD Wi rd zurückgemeldet, wenn das Target ein Kommando 

erfolgreich abgeschlossen hat. 


CHECK CONDITION Es ist bei der Kommandoausführung irgendetwas nicht 

so gelaufen, wie vorgesehen. Der Initiator sollte sich 
ausführlichere Informationen mit einem REQUEST 
SENSE-Kommando vom Target übermitteln lassen. 

CONDITION MET Wird nur in Verbindung mit den Gruppe-1 -Kommandos 

SEARCH.. auftreten. Wenn so eine Suchoperation 
erfolgreich beendet wurde, wird dies über diesen Status 
mitgeteilt. Eine Liste von verketteten Kommandos wird 
durch diese Statusmeldungen nicht unterbrochen. Die 
gesuchten Daten stehen dann in der Log. Blockadresse, 
die mit REQUEST SENSE erfragt werden kann. 

BUSY “Nicht jetzt, Liebling!” Das Target ist zur Zeit beschäf¬ 

tigt. Dieser Status sollte immer geliefert werden, wenn 
zur Zeit kein Kommando vom Initiator aufgenommen 
werden kann. Der Initiator sollte später wieder einen 
neuen Versuch starten. 

INTERMEDIATE In verketteten Kommandos (Linked Commands) ist bei 

erfolgreicher Beendigung eines jeden Teilkommandos 
(außer beim letzten Befehl!) dieser Status zurückzu- 
liefem. Wenn das nicht geschieht, wird die Kette unter¬ 
brochen und folgende, verkettete Kommandos nicht 
mehr ausgeführt. 
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RESERVATION CONFLICT Wenn der Initiator ein Gerät am Target ansprechen will, 

das für einen anderen Initiator reserviert wurde (auch das 
gibt’s bei SCSI!), wird diese Statusinformation geliefert. 


MESSAGE-Phasen 

Während der MESSAGE-Phasen können zwischen Target und Initiator Meldungen ausge¬ 
tauscht werden. Die Informationsrichtung wird dabei wieder durch den Zustand der _I/0- 
Leitung bestimmt (Low = MESSAGE IN). 

Das Target kann jederzeit in die MESSAGE IN-Phase umschalten, indem es die _MSG- 
Leitung und die J/O-Leitung aktiviert. Der Austausch der Message-Bytes geschieht wieder 
nach dem bereits beschriebenen.REQ/_ACK-Protokoll. 

Der Initiator kann selbst nicht in die MESSAGE OUT-Phase gelangen. Alle Kontrolle 
während der Transferphasen liegt ja beim Target! 

So muß der Initiator dann durch Aktivierung der Attention-Leitung (jederzeit möglich, außer 
während BUS FREE und ARBITRATION!) dem Target signalisieren, daß er Meldungen für 
das Target hat. Das T arget wird dann zum nächstmöglichen Zeitpunkt in die MESSAGE OUT- 
Phase wechseln (_MSG und _C/D aktivieren, _I/0 auf High). Datenaustausch wieder gemäß 
dem _REQ/_ACK-Verfahren. Es werden so lange Meldungen vom Initiator angefordert, bis 
dieser _ATN deaktiviert! 

Von der MESSAGE-Phase kann das Target wieder zu irgendeiner der Transferphasen 
wechseln oder in die BUS FREE-Phase gehen. Alle SCSI-Devices sollen zumindest die 
Meldung “COMMAND COMPLETE” beherrschen. Diese wird vom Target zum Abschluß 
einer Operation an den Initiator gesendet (nach derSTATUS-Phase). Der Atari-Festplattentreiber 
(in der Version 4.02) ignoriert diese Meldung einfach und verläßt sich nur auf das während 
der STATUS-Phase zurückgegebene Statusbyte. 

Entsprechend der SCSI-Norm sollte der Initiator sich bereits während der SELECTION-Phase 
mit aktiviertem _ATN beim Target vorstellen, wenn er Wert auf einen ausführlichen Mel¬ 
dungsaustausch legt. Dadurch wird das Target veranlaßt, nach erfolgreicher SELECTION in 
die MESSAGE OUT-Phase zu wechseln, um dem Initiator die Möglichkeit zu geben, sich mit 
seinen Möglichkeiten (Identify-Message) vorzustellen. 

Auf die Einzelheiten zu den Meldungen während der MESSAGE-Phasen soll hier aus Platz¬ 
gründen jedoch nicht weiter eingegangen werden. 

In folgender Tabelle finden Sie die wesentlichen Messages mit ihrer Kurzbezeichnung. 
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Message Codes 


Code 

Kurzbezeichnung 

MSG-Phase 

00H 

COMMAND COMPLETE 

In 

01H 

EXTENDED MESSAGE 

In Out 

02H 

SAVE DATA POINTER 

In 

03H 

RESTORE POINTERS 

In 

04H 

DISCONNECT 

In 

05H 

INITIATOR DETECTED ERROR 

Out 

06H 

ABORT 

Out 

07H 

MESSAGE REJECTIn 

Out 

08H 

NO OPERATION 

Out 

09H 

MESSAGE PARTTY ERROR 

Out 

OAH 

LINKED COMMAND COMPLETE 

In 

OBH 

LINKED COMMAND COMPLETE (WITH FLAG) 

In 

OCH 

BUS DEVICE RESET 

Out 

ODH.. 7FH 
80H.. FFH 

Reserved Codes 

IDENTIFY 

In Out 


Wer sich darüber weiter informieren will (oder muß), sollte z. B. auf die SCSI-ANSI-Unter- 
lagen X3T9.2, Rev. 17B, zurückgreifen, die alle nötigen Angaben in knapper Form auf ca. 200 
Seiten enthalten. Außerdem lassen sich viele Festplattenhersteller in ihren Dokumentationen 
zu SCSI-Platten zum Teil recht ausführlich über den SCSI-Standard aus. 


Die SCSI-Kommandos 

Alle SCSI-Kommandos gehen davon aus, daß SCSI-Geräte Daten in Form von aufeinander 
folgenden log. Blöcken bereitstellen bzw. entgegennehmen können. Die Übersetzung dieser 
log. Blöcke in physikalische Strukturen ist Aufgabe des SCSI-Devices. Bei SCSI-Festplatten 
werden also solche logischen Blocknummem vom SCSI-Controller der Platte in entsprechen¬ 
de Zylinder-, Sektor- und Kopfnummem umgesetzt. 

Mit jedem Kommando können ein oder mehrere log, Blocks bearbeitet werden. Mehrere Kom¬ 
mandos können hintereinander gekettet werden (Linked Commands), ohne vorher über BUS 
FREE, ARBITRATION und SELECTION gehen zu müssen. 

Nach Beendigung eines Kommandos liefert das Target ein Statusbyte (während der STATUS- 
Phase!) an den Initiator. Da in einem Byte nicht besonders viele Statusinformationen unterge¬ 
bracht werden können, kann ein Target den sogenannten CHECK CONDITION-Status zu- 
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rückmelden. Der Initiator sollte dann mit einem speziellen Kommando (REQUEST SENSE) 
die zusätzlichen Statusinformationen von dem Target einiesen. 


Der Command Descriptor Block 

Der Initiator sendet an das Target einen Command Descriptor Block (CDB), der aus 6,10 oder 
12 Bytes bestehen kann. Zusätzlich zu den in diesem Block enthaltenen Daten können weitere 
Informationen während einer DAT A OUT-Phase hinterhergesendet werden. So wird zum Bei¬ 
spiel in einem CDB einer SCSI-Platte mitgeteilt, daß ab log. Blocknummer X jetzt eine Anzahl 
von Y Datenblöcken geschrieben werden soll. Die Datenblöcke selbst werden dann in einer 
DATA OUT-Phase hinterhergesendet. Der prinzipielle Aufbau der drei möglichen Formen 
eines CDB sieht folgendermaßen aus: 


Command Descriptor Block - 6 Bytes - 


Bit 

Byte 

7 6 5 

4 3 2 1 0 

0 

Gruppen-Code 

Command Code 

1 

Logical Unit 

Log. Blockadresse (MSB) 

2 

Log. Blockadresse 

3 

Log. Blockadresse (LSB) 

4 

Transferlänge 

5 

Control Byte 


Command Descriptor Block -10 Bytes - 


Bit 

Byte 

7 6 5 

4 3 2 1 

0 

0 

Gruppen-Code 

Command Code 

1 

Logical Unit 

Reserviert 

RelAdr 

2 

Log. Blockadresse (MSB) 

3 

Log. Blockadresse 

4 

Log. Blockadresse 

5 

Log. Blockadresse (LSB) 

6 

Reserviert 

7 

Transferlänge (MSB) 

8 

Transferlänge (LSB) 

9 

Control Byte 
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Command Descriptor Block -12 Bytes - 


Bit 

Byte 

7 6 5 

4 3 2 1 

0 

0 

Gruppen-Code 

Command Code 

1 

Logical Unit 

Reserviert 

RelAdr 

2 

Log. Blockadresse (MSB) 

3 

Log. Blockadresse 

4 

Log. Blockadresse 

5 

Log. Blockadresse (LSB) 

6 

Reserviert 

7 

Reserviert 

8 

Reserviert 

9 

Transferlänge (MSB) 

10 

Transferlänge (LSB) 

11 

Control Byte 


Byte 0 


Jedes Kommando beginnt mit einem Byte für den Operation Code (OP-Code). 

Dabei wird durch die höchstwertigen drei Bits im OP-Code die Gruppenzugehörigkeit (Grup- 
pen-Code) des Kommandos ausgedrückt. 


Gruppe 0 
Gruppe 1 
Gruppe 2-4 
Gruppe 5 
Gruppe 6-7 


Kommandos mit 6 Bytes 
Kommandos mit 10 Bytes 
Reserviert 

Kommandos mit 12 Bytes 
Herstellerspezifische Kommandos 


In jeder Gruppe sind dann noch 5 Bits für den Command-Code vorgesehen, durch die dann 
32 verschiedene Befehle dargestellt werden können. 

Logical Unit 

Da ja ein Target durchaus mehr als ein Peripheriegerät steuern kann, müssen diese natürlich 
voneinander unterschieden werden. 

Über die drei Bits für die LUN (=Logical Unit) lassen sich so bis zu acht Geräte pro SCSI- 
Device unterscheiden. 
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Log. Blockadresse 

Hierüber wird die Nummer des anzusprechenden log. Blocks mitgeteilt. Log. Blocks beginnen 
mit der Nummer 0 und werden in ununterbrochener Reihe fortgezählt. Bei Gruppe O-Kom- 
mandos stehen insgesamt “nur” 21 Bits für die LBA (Log. Blockadresse) zur Verfügung. Da¬ 
mit kann man immerhin schon über 2 Millionen log. Blockadressen ansprechen. 

Bei den Gruppe 1- und 5-Kommandos sind dann über 4,2 Milliarden (!) Blöcke ansprechbar. 

Da log. Blocks eine unterschiedliche Zahl von Datenbytes beinhalten können, sollte schon 
eine Abstimmung über die Blockgröße zwischen Initiator und Target vorgenommen sein. 
Über Befehle wie MODE SENSE oder READ CAPACITY kann der Initiator zum Beispiel 
die Blockgröße vom Target erfragen. 

Relative Address Bit (RelAdr) 

Dieses Bit wird nur bei Gruppe 1 und 5-Kommandos im Zusammenhang mit verketteten 
Befehlen (Linked Commands) verwendet. Wenn das Bit gesetzt ist, handelt es sich bei der Log. 
Blockadresse nicht um eine absolute, sondern um eine relative Blocknummer. 

Diese relative Blocknummer (in 2er-Komplement-Darstellung; positiver oder negativer 
Wert!) wird zu der letzten verwendeten absoluten Log. Blockadresse addiert. Das Ergebnis 
ist dann die gewünschte LBA! 

Transferlänge 

Durch diesen Wert wird üblicherweise angegeben, wie viele log. Blocks übertragen werden 
sollen. Manche Kommandos enthalten allerdings in dem Feld Transferlänge die Anzahl der 
zu übertragenden Bytes (z. B. REQUEST SENSE). 

Wenn für die Angabe der Transferlänge nur 1 Byte verwendet wird, können maximal 256 
Blocks in einem Rutsch übertragen werden. Dabei steht ein Wert von Null für 256 Blocks! Alle 
anderen Werte zwischen 1..255 werden durch den entsprechenden Zahlenwert ausgedrückt. 

In Befehlen, die zwei Bytes für die Transferlänge zur Verfügung stellen, können maximal 
65536 Blöcke pro Kommando übertragen werden. Auch hier wird die höchste Blockanzahl 
wieder durch den Wert von Null im Transferlängenfeld dargestellt. 

Control Byte 

Das jeweils letzte Byte in einem CDB ist das Control Byte. Es hat den folgenden Aufbau; 
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Control Byte 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

LAST 

Herstellerspez. 

Reserviert 

Flag 

Link 


Link Bei einem gesetzten B it wird dem Target signalisiert, daß es sich um eine Verkettung 

von Befehlen handelt. Es werden also weitere Befehle vom Initiator ans Target gelie¬ 
fert. 

Targets, die diese “Linked Commands” unterstützen, liefern bei erfolgreicher Kom¬ 
mandoausführung in der STATUS-Phase ein INTERMEDIATE-Statusbyte. Außer¬ 
dem wird eine entsprechende Meldung (“LINKED COMMAND COMPLETE” 
bzw. “LINKED COMMAND COMPLETE (WITH FLAG)” in einer MESS AGEIN- 
Phase an den Initiator geliefert. 

Bei Targets, die nicht mit “Linked Commands” klarkommen, wird am Ende der Ope¬ 
ration ein CHECK CONDITION-Statusbyte geliefert. Wenn man (der Initiator) 
dann mit einem REQUEST SENSE-Befehl beim T arget nachfragt, was denn war, er¬ 
hält man in diesem Falle ein “ILLEGAL REQUEST” signalisiert. 

Flag Dieses Bit wird nur in Verbindung mit dem Link-Bit benutzt und legt fest, welche 
Meldung (LINKED COMMAND COMPLETE bei Flag=0, LINKED COMMAND 
COMPLETE (WITH FLAG) bei Flag =1) an den Initiator gesendet wird. Typische 
Anwendung für dieses Bit ist die Verursachung eines Interrupts zwischen zwei Link¬ 
ed Commands im Initiator. 


Gruppe O-Kommandos 

Im folgenden sollen die wichtigsten Gruppe O-Kommandos für “Direct-Access Devices” laut 
SCSI erläutert werden. Diese Kommandos werden deshalb auch von nahezu allen SCSI- 
Festplatten “verstanden” und sind deshalb auch in mancher Harddisk-Software (Treiber und 
Tools wie AHDI 4.02, SCSITOOL 2.09 und HUSHI 2.12) zu finden. 

TEST UNIT READY 

Mit diesem Kommando wird getestet, ob die angesprochene LUN (Logical UNit) des ange¬ 
sprochenen Targets bereit ist. Damit wird nicht etwa ein Selbsttest angestoßen. Wenn die 
angesprochene LUN bereit für den Zugriff auf das Medium ist, liefert der TEST UNIT 
READY-Befehl einen GOOD-Status zurück. 
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TEST UNIT READY (OP-Code 00H) 


Bit 

Byte 

7 

6 

5 

■ 

3 

2 


0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

Logical Unit 

Reserviert 

2 

Reserviert 

3 

Reserviert 

4 

Reserviert 

5 

Herstellerspez. 

Reserviert 

Flag Link 


REZEROUNIT 

Das Target soll die angesprochene LUN in einen speziellen Anfangszustand versetzen (lt. 
SCSI). Bei Festplatten wird man mit diesem Kommando die Platte auf Zylinder 0 fahren (nicht 
zu verwechseln mit dem “Parken” von Festplatten! Das wird mit dem STOP-Befehl reali¬ 
siert). 


REZERO UNIT (OP-Code 01H) 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

1 

Logical Unit 

Reserviert 

2 

Reserviert 

3 

Reserviert 

4 

Reserviert 

5 

Herstellerspez. 

Reserviert 

Flag 

Link 


REQUEST SENSE 

Mit diesem Befehl lassen sich in der an die COMMAND-Phase anschließenden DATA IN- 
Phase Sense-Daten vom Target einiesen. Diese Sense-Daten (Sense = Bedeutung, Befinden) 
liefern weitere Informationen über die Ursache einer Störung, die mit einem CHECK 
CONDITION-Status nach Abschluß eines anderen Kommandos an den Initiator signalisiert 
wurde. Sense-Daten werden vom Target nach einer Störung so lange bereitgehalten, bis sie 
durch diesen Befehl “abgeholt” werden oder ein anderer Befehl (vom gleichen Initiator, dem 
CHECK CONDITION gemeldet wurde) ausgeführt wird. 
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REQUEST SENSE (OP-Code 03H) 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

0 

0 

o 

0 

0 

0 

1 

1 

T 

Logical Unit 

Reserviert 

2 

Reserviert 

3 

Reserviert 

4 

Transferlänge 

5 

Herstellerspez. 

Reserviert 

Flag 

| Link 


Im Feld Transferlänge übermittelt der Initiator dem Target, wie viele Bytes Sense-Daten er 
vom Target maximal aufhehmen kann! Das Target beendet dann die folgende DATA IN- 
Phase, wenn diese Zahl von Bytes an den Initiator übermittelt ist (auch wenn noch mehr Bytes 
zur Verfügung stünden!) oder wenn alle Sense-Daten übermittelt sind. Bei einerTransferlänge 
von Null sendet das Target übrigens trotzdem (gern. SCSI-Vereinbarung) vier Sense-Daten¬ 
bytes! 

Man unterscheidet zwei Formate bei den übermittelten Sense-Daten, wobei das Format durch 
die Art des Fehlers bestimmt wird. Genauer gesagt, in welche Klasse der Fehler eingeordnet 
wird: 

Nonextended Sense Für die Fehlerklassen 0..6 (Error dass 0..6) kommt ein 4-Byte-For- 
mat zur Anwendung. 

NONEXTENDED SENSE DATA FORMAT 


Bit 

7 

6 

5 

4 

3 

2 

1 j 0 

Byte 








0 

Ad Valid 

Fehlerklasse 

Fehlercode 

1 

Herstellerspezifisch 

Logische Blockadresse 

(MSB) 

2 

Logische Blockadresse 

lJ_ 




Logische Blockadresse 

(LSB) 


Ad Valid Wenn dieses Bit gesetzt ist, steht die gelieferte Logische Blockadresse 

in direkter Beziehung zu dem Fehler (wenn bei einem Festplatten¬ 
zugriff z. B. ein Lesefehler auftrat, wird man per REQUEST SENSE 
dann in der log. Blockadresse die Nummer des Blocks übermittelt 
bekommen, der nicht gelesen werden konnte!) 
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Fehlerklasse Herstellerspezifische Nummer, mit der der Fehler klassifiziert wird 

(Fehlerwichtigkeit). 

Fehlercode FehlemummerineinerbestimmtenFehlerklasse. Herstellerspezifisch. 

Einige Plattenhersteller liefern im Fehlercode den gleichen Wert wie 
im Sense Key-Feld beim Extended Sense-Format! 

Häufiger anzutreffen ist das erweiterte Format für Sense-Daten. Vielfach liefern Targets nur 
bei einer Transferlänge von Null im REQUEST SENSE-Befehl das “kurze” Sense-Data-For- 
mat. 

Extended Sense Dieses Format umfaßt mindestens acht Sense-Datenbytes! Es wird 

nur bei der Fehlerklasse 7 verwendet 

Folgendes Format wird benutzt: 

EXTENDED SENSE DATA FORMAT 


Bit 

Byte 

7 

6 

5 

4 

3 2 10 

0 

Valid 

Fehlerklasse (= 7) 

Fehlercode (= 0) 

1 

Segmentnummer 

2 

FM 

EOM 

| ILI 

Reserv. Sense Key 

3-6 

(MSB) Informationsbytes (LSB) 

7 

Anzahl zusätzlicher Sense Bytes (n) 


Zusätzliche Sense Bytes 


Die Fehlerklasse 7 steht für Extended Sense! Steht dann im Fehlercode eine 0, wird die oben 
gezeigte Datenstruktur verwendet. Die Fehlercodes 1 ,.E H sind reserviert. Bei einem Fehlercode 
von F H kommt ein herstellerspezifisches Datenformat zur Anwendung (bei SCSI-Festplatten 
aber nicht anzutreffen!). 

Valid Wenn das Bit gesetzt ist, sind die Informationsbytes in den Sense- 

Bytes 3..6 auch gültig. Üblicherweise findet man hier dann die log. 
Blockadresse, die mit der Fehlermeldung im Zusammenhang steht. 

Segmentnummer Tritt nur bei Fehlem in Zusammenhang mit speziellen Befehlen wie 
COPY, COMPARE und COP Y WITH VERIF Y auf. Bei diesen Be¬ 
fehlen können zu kopierende/vergleichende Datenbereiche in söge- 
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FM 


EOM 


ILI 


Sense Key 


nannten Segmentdeskriptoren (“Bereichs-Beschreibem”) festgelegt 
werden. Die Segmentnummer liefert in diesem Fall die Nummer des 
Segmentdeskriptors, der mit dem Fehler in Zusammenhang steht. 

In den Informationsbytes ist dann ein Zahlenwert in Zweierkomple- 
mentdarstellung enthalten, der darauf schließen läßt, an welcher Stel¬ 
le (Block/Byte) in dem Segment der Fehler aufgetreten ist. 

File Mark-Bit. Nur bei sequentiell arbeitenden Peripheriegeräten 
eines Targets (z. B. Bandlaufwerke) verwendet. Filemarken werden 
zum Auffinden bestimmter, zusammengehöriger Datenstrukturen 
(ähnlich den Adreßfeldmarken in einer Spur bei Floppy-Disks) be¬ 
nutzt. Wenn das Bit gesetzt wird, ist eine Filemarke erkannt worden. 

End-of-Medium-Bit. Wird nur bei sequentiellen Peripheriegeräten 
und Printer-Devices gebraucht. Bei gesetztem Bit wird auf einen 
End-of-Medium-Zustand aufmerksam gemacht (Band befindet sich 
am Ende oder beim Rückspulen ganz am Anfang! Papier ist zu Ende 
o. ä). 

Incorrect length indicator. Wird gesetzt, wenn die im Kommando 
geforderte log. Blockgröße nicht mit der auf dem Medium “harmo¬ 
niert”! 


“Bedeutungs-Schlüssel”. HiermitistebenfallssoeineArtFehlergrup- 
pierung möglich. Beispielsweise ließen sich damit, je nach Sense 
Key, unterschiedliche Fehlerbehandlungen durch den Initiator reali¬ 
sieren. 


Nachfolgend eine Tabelle mit den Sense Keys nach SCSI-Standard: 


Sense Key 

Bedeutung 

o H 

NO SENSE. Keine besonderen Vorkommnisse (die einer Sense-Information 
bedürfen). Diesen Key erhält man, wenn REQUEST SENSE nach einem 
korrekt ausgeführten Befehl ausgeführt wird (Statusbyte war GOOD!). 


Aber auch bei einem mit CHECK CONDITION abgeschlossenen Kommando 
gibt es diesen Key, wenn z. B. nur eine Filemark oder End-of-Medium erkannt 
wurde. 
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Sense Key Bedeutung 

1 H RECOVERED ERROR. Da war wohl ein Fehler, aber er konnte durchs Target 

noch während der Ausführung korrigiert werden. 

2 h NOT READY. Gewünschte LUN ist nicht bereit. 

3 h MEDIUM ERROR. Fehler auf dem Medium (der nicht korrigiert werden 

konnte!). 

4 h HARDWARE ERROR. Nichtbehebbarer Fehler in der Hardware. 

5 h ILLEGAL REQUEST. Im Command Descriptor Block oder den zusätzlich 

zum Kommando gehörenden Daten waren ungültige Parameter. 

6 h UNIT ATTENTION. Target wurde zurückgesetzt oder das Medium gewech¬ 

selt. 

7 h DATA PROTECT. Der per Kommando angesprochene Block ist von der 

gewünschten Operation ausgenommen. (Schreib/Leseschutz). 

8 h BLANK CHECK. Bei einem sequentiell arbeitenden Device oder einem 

“Write-once read-multiple”-Device (=WORM-Device; nur einmal beschreib¬ 
bares, aber beliebig oft lesbares Medium wie z. B. Optical Disk) wurde ein 
“blanker” Block (nicht initialisierter Block) beim Lesezugriff erkannt. 

Oder bei einem WORM-Device mit sequentiellem Zugriff wurde ein bereits 
mit Daten gefüllter Block beim Schreibzugriff erkannt. 

9 h Herstellerspezifischer Sense Key. 

A h COPY ABORTED. COPY-, COMPARE- oder COPY AND VERIFY-Kom- 

mando wurde abgebrochen. 

B (| ABORTED COMMAND. Der letzte Befehl wurde vom Target abgebrochen. 

Ein weiterer Versuch vom Initiator könnte nichts schaden. 

C H EQUAL. Bei einem SEARCH DATA-Kommando wurde die Gleichheitsbedin¬ 

gung erfüllt. 

D H VOLUME OVERFLOW. Ein mit Pufferspeicher arbeitendes Gerät hat bei 

einem Schreibzugriff das Ende des Mediums erreicht. Dabei konnten nicht 
mehr alle Daten im Puffer auf dem Medium untergebracht werden. 
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Sense Key 

Bedeutung 

E h 

MISCOMPARE. Bei einem Vergleich wurde festgestellt, daß die Quelldaten 
vom Initiator nicht mit vom Medium gelesenen Daten übereinstimmen. 


Reserviert! 


Die meisten Festplattenhersteller liefern zusätzlich zu diesen Extended Sense-Bytes noch 
weitere spezielle Informationen. Die Verlängerung der Extended Sense-Liste ist durch das 
Feld Additional Length um die dort eingetragene Byteanzahl möglich. 

Nahezu alle SCSI-Festplatten liefern in den zusätzlichen Sense-Bytes an Byte-Position 12 
einen zusätzlichen Sense-Code. Außerdem wird dieser Sense-Code bei manchen Festplatten 
auch im ersten Byte des Nonextended Sense-Format geliefert. 

Der zusätzliche Sense Code gibt dann noch genaueren Aufschluß über Fehlerzustände der 
Platte oder des Controllers. Man wird aber dann nicht umhin kommen, sich mit der Hersteller- 
Dokumentation zu “bewaffnen”, um den Fehlerursachen genau auf den Grund zu gehen. Zum 
Glück hatten viele Plattenhersteller “die gleichen Ideen”, was diesen Sense-Code angeht. Man 
entdeckt so viele “Gemeinsamkeiten” beim Vergleich der Sense-Codes unterschiedlicher 
Plattenhersteller. 


FORMAT UNIT 

Mit diesem Befehl wird das Peripheriegerät angewiesen, das Medium zu formatieren. 

Damitistnach Abschluß des Kommandos gewährleistet, daß auf alle verfügbaren Datenblöcke 
zugegriffen werden kann. 


FORMAT UNIT (OP-Code Ö4H) 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

0 

o 

0 

0 

0 

1 

0 

_ 0 

1 

Logical Unit 

FmtDa 

CmpLst 

Defektlistenformat 

2 

Herstellerspezifisch 

3 

Interleave (MSB) 

4 

Interleave (MSB) 

| 5 

Herstellerspez. Reserviert 

Flag | Link 
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Im Byte 2 des Kommandos erlauben manche Plattenhersteller die Angabe des Bitmusters, 
welches beim Formatiervorgang in die Sektoren geschrieben wird. Ähnlich dem Virgin-Byte 
bei der Floppy-Disk-Formatierroutine des XBios (Flopfmt) im XBios des ST(E)/TT. 

Bei Interleave kann eine spezielle Zuordnung zwischen der Reihenfolge der log. Blöcke und 
den dazugehörigen physikalischen Blocks angegeben werden. 


FmtData Nach dem FORMATUNIT-Kommando folgteineDATAOUT-Pha- 

se, wenn dieses Bit gesetzt ist. Damit wird üblicherweise eine Liste 
mit defekten Stellen an das Target übermittelt, die beim Formatiervor- 
gang übersprungen werden sollen. 

CmpLst Wenn das Bit gesetzt ist, muß das Target davon ausgehen, daß in der 

während der DATA OUT-Phase gelieferten Liste alle bekannten 
Defektstellen enthalten sind. Eine im Target vorhandene, ältere 
Defektliste ist dann nicht mehr zu verwenden! Wenn das Bit gelöscht 
ist, soll zu der bereits im Target existierenden Liste mit Defektstellen 
die vom Initiator gesendete Defektliste zusätzlich verwendet werden. 

Alle beim Formatiervorgang gefundenen neuen Defektstellen wer¬ 
den zu den bereits bekannten Defekten (ob im Target vorhanden oder 
vom Initiator während einer DATA OUT-Phase geliefert) “dazu¬ 
gepackt”! 


Defektlistenformat Diese drei Bits bestimmen, zusammen mit den FmtData- und CmpLst- 

Bits, den Aufbau der resultierenden Defektliste und deren Verwen¬ 
dung für den Formatiervorgang. Nicht alle SCSI-Platten beherrschen 
alle nachfolgenden Kombinationen! 


4 3 2 1 0 

Fmt Data 

Cmp Lst 

[ Defektlistformat 


Bemerkungen 


0 X X X X Formatieren ohne Defektliste vom Initiator! Es wird nur 

die im Target vorhandene Defektliste (bestehend aus vom 
Hersteller eingetragenen Defekten und bisher erkannten 
Defektstellen) verwendet. Diese Option verstehen wohl 
alle Platten! 
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4 3 2 1 0 

Fmt Data 

Cmp Lst 


Bemerkungen 


1 0 0 X X Zusätzlich zu den bekannten Defektstellen im Target 

(Known defect list) sollen die vom Initiator gelieferten 
Defektstellen berücksichtigt werden. Für die Defektliste 
vom Initiator wird das log. Blockformat (Format A) 
benutzt. 

1 1 0 X X Die vom Initiator gelieferte Defektliste soll als vollstän¬ 

dige Liste aller Defekte benutzt werden (also keine Liste 
aus dem Target benutzen!). Die gelieferte Defektliste ent¬ 
hält die Defektstellen im log. Blockformat (Format A). 

10 10 0 Zusätzlich zur Known defect list im Target sind die vom 

Initiator gelieferten Defektstellen zu berücksichtigen. 
Die Liste liegt als Liste derphys. Sektoren vor (Format B). 

1110 0 Die vom Initiator gelieferte Defektliste soll als vollstän¬ 

dige Liste aller Defekte benutzt werden (also keine Liste 
aus dem Target benutzen!). Die gelieferte Defektliste 
enthält die Defektstellen als Liste von phys. Sektoren 
(Format B). 

10 10 1 Zusätzlich zur Known defect list im Target sind die vom 

Initiator gelieferten Defektstellen zu berücksichtigen. 
Die Liste liegt in Form von Byte-Abständen vom Index¬ 
impuls vor (Format €). 

1110 1 Die vom Initiator gelieferte Defektliste soll als vollstän¬ 

dige Liste aller Defekte benutzt werden (also keine Liste 
aus dem Target benutzen!). Die Liste liegt in Form von 
Byte-Abständen vom Indeximpuls vor (Format C). 

Andere Kombinationen sind herstellerspezifisch bzw. reserviert! Nachfolgend die drei 

möglichen Formate für die Defektliste, welche während einer DATA OUT-Phase vom Initia- 
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tor an das Target übermittelt werden kann. Dabei weist jede Liste zu Beginn den sogenannten 
Defect List Header auf, der letztlich enthält, wie viele Bytes an eigentlicher Defektinformation 
noch folgen. 

Defektliste im iog. Blockformat (Format A) 


Byte 

Defect List Header 

0 

Reserviert 

1 

Reserviert 

2 

Defektlistenlänge (MSB) 

3 

Defektlistenlänge (LSB) 


Defect Descriptor(s) 

0 

Def. Blockadr. (MSB) 

1 

Def. Blockadr. 

2 

Def. Blockadr. 

3 

Def. Blockadr. (LSB) 


Jeder Defect Descriptorenthälteine Log. Blockadresse und be!egt4Bytes in der Descriptorliste. 
Die Defect Deskriptoren sind in aufsteigender Form zu liefern. 

Defektliste im phys. Sektorformat (Format B) 


Byte 

Defect List Header 

0 

Reserviert 

1 

Reserviert 

2 

Defektlistenlänge (MSB) 

3 

Defektlistenlänge (LSB) 


Defect Descriptor(s) 

0 

Zylindemummer (MSB) 

1 

Zylindemummer 

2 

Zylindemummer (LSB) 

3 

Kopfnummer 

4 

Sektomummer (MSB) 

5 

Sektomummer 

6 

Sektomummer 

7 

Sektornummer (LSB) 
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Jeder Defect Descriptor enthält die Position des Defekts durch Angabe des Zylinders, der 
Kopfnununer und der Sektomummer. 

Jeder Defect Descriptor belegt 8 Bytes in der Liste. 

Auch hier sind die Defekte in aufsteigender Folge anzugeben. Dabei wird die Zylindemummer 
am stärksten gewichtet, dann die Kopfnummer, und als niedrigste Gewichtung wird die Sek- 
tomummmer verwendet. Wird bei Sektomummer $FFFFFFFF angegeben, so ist der ganze 
Track als defekt anzusehen. 

Defektliste im “Byte-from-Index”-Format (Format C) 


Byte 

Defect List Header 

0 

Reserviert 

1 

Reserviert 

2 

Defektlistenlänge (MSB) 

3 

Defektlistenlänge (LSB) 


Defect Descriptor(s) 

0 

Zylindemummer (MSB) 

1 

Zylindemummer 

2 

Zylindernummer (LSB) 

3 

Kopfnummer 

4 

Bytes-from-Index (MSB) 

5 

Bytes-from-Index 

6 

Bytes-from-Index 

7 

Bytes-from-Index (LSB) 


Jeder Defect Descriptor enthält die Position des Defekts durch Angabe des Zylinders, der 
Kopfnummer und der Entfernung des Defekts in Bytes vom Indeximpuls. Dabei umfaßt eine 
Defektstelle lt. SCSI immer einen Bereich von 8 Bytes! 

Jeder Defect Descriptor belegt 8 Bytes in der Liste. 

Auch hier sind die Defekte in aufsteigender Folge anzugeben. Dabei wird die Zylindemummer 
am stärksten gewichtet, dann die Kopfnummer, und als niedrigste Gewichtung wird die Ent- 
femungsangabe in Bytes vom Indeximpuls gewertet. 

Bei $FFFFFFFF in “Bytes-from-Index” ist der gesamte Track als defekt zu betrachten. 




1100 


ATARI Profibuch 


Die meisten Plattenhersteller benutzen noch einige Bits in Byte 1 des Defect List Headers, um 
bestimmte “Anweisungen” an die Platte zu übermitteln. 


Defect List Header 


Bit 

Byte 

7 

6 

5 

B 

3 

2 

B 

0 

0 

Reserviert 

1 

FOV 

DPRY 

DCRT 

STPF 


2 

Defektlistenlänge (MSB) 

3 

Defektlistenlänge (LSB) 


FOV Format Options Valid. Wenn dieses Bit gesetzt ist, werden die Bits 4..6 in 

diesem Byte in ihrer Einstellung beim Formatiervorgang berücksichtigt. Bei 
gelöschtem FOV-Bit wird mit Standardvorgaben für die Bits 4..6 dieses Bytes 
gearbeitet. 

DPRY Disable Primary Defect List. Bei gesetztem Bit wird die bei der Fabrikation der 

Platte aufgebrachte Defektliste beim Formatiervorgang nicht berücksichtigt! 

DCRT Disable Media Certification. Bei gesetztem Bit werden die während eines For¬ 

matiervorgangs gefundenen neuen Defektstellen nicht mit in die Defektliste 
auf genommen'. 

STPF Stop Format on Error. Bei gesetztem Bit wird ein Formatiervorgang abgebro¬ 

chen (mit Status = CHECK CONDITION), wenn die Defektliste nicht vom 
Medium gelesen werden konnte. Also dann, wenn die Defektliste der Platte 
selbst einen Defekt aufweist. Bei gelöschtem Bit wird normal weiterformatiert. 

REASSIGN BLOCKS 

Mit diesem Befehl lassen sich defekte log. Blocks ausklammem und statt dessen (für solche 
Zwecke vorgesehene) Reserveblocks verwenden. Der Peripherie-Controller wird dann bei 
einem Zugriff auf einen ursprünglich defekten Block diesen Zugriff auf den Reserveblock um¬ 
lenken. Auch bereits schon mal neu zugeordnete Blöcke (Reassigned Blocks), die sich im Lau¬ 
fe der Zeit als defekt heraussteilen, können wiederum durch andere Reserveblocks ersetzt wer¬ 
den, bis halt keine Reserven mehr da sind! 

Die bei einem Reassign herbeigeführte Neu-Zuordnung eines log. Blocks ist in der Regel mit 
der Änderung des Blockinhalts verbunden! 
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Viele SCSI-Platten führen eine solche Reassign-Operation selbst durch, wenn bei einem Zu¬ 
griff festgestellt wurde, daß der gewünschte Block defekt ist. 


REASSIGN BLOCKS (OP-Code 07H) 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

0 

0 

0 

0 

0 

1 

1 

1 

1 

Logical Unit 

Reserviert 

2 

Reserviert 

3 

Reserviert 

4 

Reserviert 

5 

Herstellerspez. 

Reserviert 

Flag 

Link 


Auch bei diesem Kommando folgt eine DATA OUT-Phase, in der die Liste mit den defekten 
Blöcken (Defektliste) an das Target zum Reassign übergeben wird. Der Aufbau dieser Liste 
ist der gleiche wie bei der Defektliste im log. Blockformat (Format A) beim FORMAT UNIT- 
Befehl! 

READ 

Mit diesem Befehl wird das Target veranlaßt, Daten von der gewünschten LUN an den Initiator 
zu senden. An das Kommando schließt sich also eine DATA IN-Phase an. Es lassen sich dabei 
bis zu 256 Blöcke vom Target einiesen. Die Blockanzahl ist im Feld Transferlänge einzutragen 
(0=256 Blocks!). Durch die 21 Bits für die Blockadresse kann mit diesem 6-Byte-Kommando 
immerhin schon auf über 2 Millionen Blocks zugegriffen werden. Bei einer log. Blockgröße 
vonüblicherweise512 Bytes erlaubt dieserBefehl also Zugriffeauf immerhin 1 GByte Daten! 


READ (OP-Code 08H) 


Bit 

Byte 

7 

6 

5 

4 

3 


1 

0 

0 

0 

0 

0 

0 

1 

0 

0 

0 

1 

Logical Unit 

Log. Blocknummer (MSB) 

2 

Log. Blocknummer 

3 

Log. Blocknummer (LSB) 

4 

Transferlänge 

5 

Herstellerspez. 

Reserviert 

Flag Link 
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WRITE 

Dieses Kommando ist das Gegenstück zum READ-Befehl und zieht eine DATA OUT-Phase 
nach sich, während der die zu schreibenden Daten an das Target übergeben werden. 

Für Transferlänge und log. Blockadresse gilt sinngemäß das gleiche, wie bereits beim READ- 
Befehl erwähnt. 


WRITE (OP-Code OAH) 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

0 

0 

0 

0 

1 

0 

1 

0 

1 

Logical Unit 

Log. Blocknummer (MSB) 

2 

Log. Blocknummer 

3 

Log. Blocknummer (LSB) 

4 

Transferlänge 

5 

Herstellerspez. 

Reserviert 

Flag 

Link 


SEEK 


Die angesprochene Logical Unit (LUN) des Targets wird durch den SEEK-Befehl veranlaßt, 
den im Kommmando übergebenen Block anzusteuem. 

BeiPlattenwirddieses Kommando wohl kaumgebraucht, weil Zugriffeauflog. Blockadressen 
immer direkt mit READ- oder WRITE-Kommandos durchgeführt werden. 


SEEK (OP-Code OBH) 


Bit 

Byte 

7~1 

6 

5 

4 

3 

2 

1 

0 

0 



0 

0 

1 

0 

1 

1 

1 

Logical Unit 

Log. Blocknummer (MSB) 

2 

Log. Blocknummer 

3 

Log. Blocknummer (LSB) 

4 

Reserviert 

5 

Herstellerspez. 

Reserviert 

Flag 

Link 
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INQU1RY 

Mit diesem “Erkundigungs’-Kommando kann man mehr über die am Target angeschlossenen 
LUNs erfahren. 

In einer DATA IN-Phase liefert das Target dann Informationen über die angesprochene 
Logical Unit. 

Zum Teil sind in den Daten “Klartextinformationen” über den Typ der LUN enthalten. 


INQU1RY (OP-Code 12H) 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

0 

0 

0 

1 

0 

0 

1 

0 

1 

Logical Unit 

Reserviert 

2 

Reserviert 


Reserviert 


Transferlänge 

5 

Herstellerspez. 

Reserviert 

Flag 

Link 


Im Feld Transferlänge wird angegeben, wie viele Bytes der Initiator max. während der DATA 
IN-Phase vom Target aufnehmen kann. 

Die während der DATA IN-Phase gelieferten INQUIRY-Daten weisen dabei folgende 
Struktur auf: 


INQUIRYDATA 


Bit 

Byte 

7 

6 

5 4 3 

2 10 

0 

Perroheriegeräte-TvD 

1 

RMB 

Device-TvDe Oualifier 

2 

ISO-Version 

ECMA-Version 

ANSI-Version 

3 

Reserviert 

4 

Zusätzliche Bvtes (NI 

5..N+4 

Herstellerspezifische Daten 
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Peripheriegeräte-Typ 


00 H Direct-access Device (z. B. Platte) 

01 H Sequ.-access Device (z. B. Bandlaufwerk) 

02 h Drucker 

03 h Prozessor-Device 

04 h Write once, read-mult. (z. B. opt. Disk) 

05 h Read-only, dir.-Access (z. B. CD-ROM) 

Die weiteren Codekombinationen sind reserviert! 


RMB Removable Medium Bit. Wenn das Medium wechselbar ist, wird 

dieses Bit gesetzt, sonst nicht. 

Device-Type Qualifier DiesesiebenBitsstehendemAnwenderfürspezielleIdentifikatio¬ 
nen der im System verwendeten LUNs zur Verfügung. Damit 
kann der Anwender zum Beispiel durch Vergabe von solchen 
Device-Type Qualifiem (meistens mit dem Befehl MODE SE- 
LECT einstellbar) mehrere gleichartige Peripheriegeräte mit 
Wechselmedien auseinanderhalten (Wechselplatte, Streamer, 
Bandlaufwerk usw.). 

Version-Byte In diesem Byte lassen sich Informationen unterbringen, welcher 

Normenversion (ISO, ECMA und ANSI) die SCSI-Ausstattung 
(Möglichkeiten) das verwendete Gerät gerecht wird. 


Im Byte 4 steht dann eine Information, wie viele herstellerspezifische Bytes noch folgen 
werden. Wenn noch Herstellerbytes folgen, findet man in den Bytepositionen 8.. 15 der 
INQUIRY-Daten üblicherweise den Herstellemamen (im erweiterten ASCII (8 Bit)) wieder. 
Bytes 16..31 dienen meistens zur Produktbezeichnung undevtl. der Angabe vonSeriennummem 
(ebenfalls in ASCII). Weitere Bytes liefern zum Teil ebenfalls Seriennummem oder 
Versionsnummem der Hard- und Firmware sowie das Fabrikationsdatum. 


MODESELECT 


Mit diesem Kommando lassen sich in einer anschließenden DATA OUT-Phase eine Menge 
Parameter an das Target übermitteln. Wie viele Parameterbytes während der DATA OUT- 
Phase übermittelt werden, ist in dem Feld Transferlänge anzugeben. 

In der Parameterliste sind solche Angaben enthalten wie max. Blockzahl und log. Blockgröße 
in Bytes! Außerdem lassen sich verschiedene Betriebsmodi einstellen. Bei Festplatten mit 
Cache kann z. B. die Anzahl der Cachesegmente und deren Größe, bei Platten mit Shutdown- 
Funktion die Zeit, nach der diese bei “Nichtgebrauch” in einen stromsparenden Standby- 
Modus gehen, usw. eingestellt werden. 
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Üblicherweise gelten die mit MODE SELECT gemachten Einstellungen nur bis zum nächsten 
Reset/Ausschalten. Sollen diese Einstellungen allerdings ab jetzt immer gelten (bis zu irgend¬ 
einer erneuten Änderung), so müssen diese gespeichert werden. Die Speicherung wird durch 
Setzen des SP-Bits im MODE SELECT-Befehl veranlaßt. 


MODE SELECT (OP-Code 15H) 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

— 

1 

. 

0 

0 

0 

0 

0 

1 

0 

1 

0 

1 

1 

Logical Unit 

Reserviert 

SP 

2 

Reserviert 

3 

Reserviert 

4 

Transferlänge 

5 

Herstellerspez. 

Reserviert 

Flag 

Link 


Die MODE SELECT-Parameterliste weist nachfolgende Struktur auf, wobei es möglich ist, 
diese Liste um herstellerspezifische Angaben zu erweitern. 

Dabei werden diese zusätzlichen Angaben in Funktionsgruppen zusammengefaßt. So eine 
Funktionsgruppe wird als Page bezeichnet. 

Jede Page wird durch den Page-Code identifiziert, der jeweils im ersten Byte der Page auf¬ 
taucht. Damit eine Abgrenzung zu nachfolgenden Pages möglich ist, wird im zweiten Byte 
jeder Page ein entsprechender Längenwert angegeben. 

Dieser Wert enthält die Anzahl der Pagebytes, die noch nach dem Längenbyte kommen! 


Byte 

MODE SELECT Header 

0 

Reserviert 

1 

Medium-Typ (0) 

2 

Reserviert 

3 

Länge des Blockdescriptors 


Blockdescriptor(s) 

0 

Density Code 

1 

Blockanzahl (MSB) 

2 

Blockanzahl 
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Byte 

MODE SELECT Header 

3 

Blockanzahl (LSB) 

4 

Reserviert 

5 

Blockgröße (MSB) 

6 

Blockgröße 

7 

Blockgröße (LSB) 


Bei Medium-Typ sieht SCSI eine ganze Reihe von möglichen Codes vor, die sich aber 
hauptsächlich auf Flexible Disks und Magnetbänderbeziehen. Bei Fest- und Wechselplatten 
steht dort 00„! 

n 

Der Density-Code im Blockdescriptor ist auch wiederum nur für Flexible Disks gedacht und 
bei Fest-/Wechselplatten = 00 H . 

Blockanzahl spezifiziert, wie viele Blocks auf dem Medium die vorgenannte Density und die 
nachfolgende Blockgröße aufweisen. Es ist gemäß SCSI zwar möglich, auf einer LUN mehre¬ 
re Bereiche zu vereinbaren, die unterschiedliche Blockgrößen und Densities aufweisen. Dann 
sind natürlich entsprechend viele Blockdeskriptören erforderlich. Bei Platten wird man solche 
Einstellungen aber nicht finden! 

Page Descriploren 

Die bereits erwähnten Pages mit hersteilerspezifischen Parametern sind optional und schlie¬ 
ßen bei Bedarf unmittelbar an die Blockdeskriptoren an. Die Reihenfolge, in denen die Pages 
gesendet werden, ist beliebig. Es ist auch nicht erforderlich, daß jeweils immer alle Pages mit 
einem MODE SELECT-Kommando übermittelt werden. So können spezielle Einstellungen 
jederzeit durch Übermittlung nur dieser speziellen Page bei Bedarf vorgenommen werden. 


Page 

Code 

Bedeutung 

00 H 

Allgemeine Betriebsparameter 

01 H 

Parameter für Fehlerbehebung 

02 h 

Parameter für Disconnect/Reconnect-Verhalten 

03 h 

Format-Parameter 


Unveränderbare Plattenparameter (Disk Geometry) * 

05„..1F h 

Reserviert 

20„ 

Seriennummer der Platte (manchmal!) * 

21 H ..3F H 

Reserviert bzw. (sehr) herstellerspezifisch 


* = Diese Pages können nur mit MODE SENSE ausgelesen werden! 
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Es handelt sich hierbei um keinerlei bindende Zuordnung gern. SCSI. Zum Teil findet man 
jedoch bei vielen Plattenherstellem übereinstimmende Bedeutungen bei den Parametern. 


Allgemeine Betriebsparameter (Page Code 00 H ) 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

Reserv. 

Page Code - 00,, 

1 

Page-Länge (üblicherweise = 02 H ) 

2 

USG 1 RECY | STAT | UNIT ATN | Reserviert 

3 

Device-Type Qualifier 


USG Usage Counter. SCSI-Platten führen genau Buch über Schreib-/Lese- 

zugriffe und Seek-Operationen. Die dabei entstehenden Zählerstände 
können bei Überschreiten von einstellbaren Grenzwerten zu einer 
Fehlermeldung führen. Wem dieses Bit nicht gesetzt ist, wird auch 
bei Überschreiten von Zählerständen keine Fehlerbedingung gemel¬ 
det. 

RECY Recovery. Bei gesetztem Bit werden alle Fehler gemeldet (auch 

solche, die korrigiert bzw. durch einen erneuten Versuch beseitigt 
werden könnten!), und auf eine Korrektur durch den Controller wird 
verzichtet. Standardeinstellung ist ein gelöschtes Bit. Damit werden 
nur “ernsthafte” Fehler an den Initiator gemeldet. 

STAT Status. Bei gesetztem Bit werden auch Fehler gemeldet, die vom 

Kontroller durch eigene Maßnahmen behoben werden konnten. 
Normalerweise geschieht das nicht, weshalb dieses Bit dann auch 
gelöscht ist! 

UNIT ATN Unit Attention. Wem dieses Bit gesetzt ist, wird das Target beim 

ersten Kommando (außer REQUEST SENSE und INQUIRY) nach 
einemResetoderEinschalteneinCHECKCONDrriON im Statusbyte 
melden. Bei manchen Platten ist das die Defaulteinstellung, und 
somit kann man dann von diesen Platten nicht booten. Das TOS ist 
nämlich auf ein CHECK CONDITION beim Lesezugriff auf den 
Rootsektor einer Festplatte nicht vorbereitet und interpretiert diesen 
CHECK CONDITION-Status als “Platte nicht ansprechbar”. Bei den 
meisten Platten kann man dieses Bit “ausknipsen”, und damit ist das 
Problem dann wieder gelöst (wenn nicht die Firmware des Controllers 
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fehlerhaft ist und dadurch der Zustand dieses Bits immer als gesetzt 
angesehen wird. Alles schon dagewesen!). Es wird dann nach Ein¬ 
schalten oder Reset kein CHECK CONDITION-Status gemeldet. 

Das Byte 3 wird in der Page 0 häufig verwendet, um den Device-Type Qualifier setzen zu kön¬ 
nen. Siehe dazu auch beim Befehl INQU1RY. 

Parameter für Fehlerbehebung (Page Code 01 H ) 


Bit 

Byte 

7 

6 5 4 3 | 2 1 0 

0 

Reserv. 

Page Code = 01 H 

1 

Page-Länge (üblicherweise = 06„) 

2 

AWRE 1 ARRE 1 TB [ RC~1 EECH PERl DTEl DCR 


Korrekturversuche 

4 

Korrekturspanne 

L5 

Reserviert 


Reserviert 

7 

Reserviert 


Mit Page-1-Parametern läßt sich bei Platten einstellen, wie im Fehlerfall verfahren werden 

soll. 

AWRE Automatic Write Reallocation. Bei gesetztem Bit führt der Controller 

bei einem Schreibfehler wegen eines Mediumdefekts eine Art RE- 
ASSIGN durch und legt die zu schreibenden Daten in einem Reserve¬ 
block ab. Die fehl erhafte Stelle auf dem Medium wird in die Defekt¬ 
liste im Controller eingetragen. 

ARRE Automatic Read Reallocation. Funktioniert genau wie AWRE, nur 

für Fehler bei Lesezugriffen. 

TB Transfer Block. In Verbindung mit dem DTE-Bit zu sehen. Wenn bei¬ 

de Bits gesetzt sind, wird bei Lesezugriffen auch ein fehlerhafter 
Block an den Initiator übermittelt. Ist DTE gesetzt, TB aber nicht, 
wird der fehlerhafte Block nicht gesendet. 

RC Read Continuous. Bei gesetztem Bit wird bei einem Lesezugriff das 

Aussenden der Daten an denlnitiatornicht durch evü. Pausen für Feh¬ 
lerkorrekturmaßnahmen unterbrochen. Das bedeutet, daß evtl, auch 
fehlerhafte Daten gesendet werden können. 
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EEC 


PER 


DTE 


DCR 


Korrekturversuche 

Korrekturspanne 


Enable Early Correction. Wenn das Bit gesetzt ist, wird erst versucht, 
den Fehler durch Fehlerkorrektur nach einem Fehlerkorrektural¬ 
gorithmus “rauszurechnen”. Erst wenn das nicht klappt, wird ein er¬ 
neuter Zugriffsversuch aufs Medium gestartet. Wenn das Bit gelöscht 
ist, wird zuerst mit weiteren Zugriffen versucht (max. Anzahl im Feld 
“Korrekturversuche” enthalten), den Fehler zu beheben. 

Post Error-Bit. 

Gelöscht: CHECK CONDITION wird nichterzeugt, wenn es sich um 
einen Fehler handelt, der im Rahmen der Einstellungen dieser Page 
behoben werden konnte. 

Gesetzt: CHECK CONDITION wird für behebbare Fehler ebenfalls 
erzeugt und der Sense Key für ein folgendes REQUEST SENSE- 
Kommando auf “Recovered Error” gesetzt. 

Disable Transfer on Error. Bei gesetztem B it (PER-Bit muß ebenfall s 
gesetzt sein) wird sofort der CHECK CONDITION-Status geliefert. 
Datentransfers zum Initiator werden gestoppt. Der fehlerhafte Block 
wird abhängig vom TB-Bit evtl, noch gesendet! 

Wenn das Bit gelöscht ist, wird der Datentransfer komplett durchge¬ 
führt (wenn evtl. Fehler behoben werden konnten) und erst danach 
wird ein CHECK CONDITION (falls nötig) erzeugt! 

Disable Correction. Bei gesetztem Bit wird bei einem Fehler nur 
versucht, durch wiederholte Zugriffe den Fehler zu beheben. Ein 
“Herausrechnen” des Fehlers wird nicht durchgeführt. Bei gelösch¬ 
tem Bit wird auch versucht, den Fehler mit Hilfe eines Error Correct- 
ing Codes (ECC) zu beseitigen. 

Anzahl der Korrekturversuche durch erneutes Lesen, bevor evtl, mit 
Fehlerkorrekturcode-Einsatz (ECC) gearbeitet wird. 

Max. Größe in Bits, die ein Lesefehler “lang” sein darf, bei dem es 
sich noch lohnt, mit Fehlerkorrekturcode eine Behebung durchzufüh¬ 
ren (Werte um 8.. 10 sind gebräuchlich). 


Da im TT nicht mit DISCONNECT und RECONNECT-Messages gearbeitet wird, wird auf 
den Aufbau der Page 2 nicht weiter eingegangen. Außerdem bieten nur wenige Plattentypen 
Einstellmöglichkeiten in dieser Page! 
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Format-Parameter (Page Code 03 H ) 


Bit 

Byte 

7 

6 

5 


3 | 2 

1 

0 

-- 

0 

Reserv. 

Page Code = 03 H 

1 

Page-Länge (üblicherweise = 16 H ) 

Behandlung von Defektstellen 

2-3 

(MSB) 


Anzahl Spuren pro Zone (Zylinder) 


(LSB) 

4-5 

(MSB) 


Anzahl Ausweichsektoren pro Zone 


(LSB) 

6-7 

(MSB) 


Anzahl Ausweichspuren pro Zone 


(LSB) 


(MSB) 


Anzahl Ausweichspuren pro Medium 


(LSB) 

Angaben zum Svurformat 

10-11 

(MSB) 


Sektoren/Spur (bei variabler Zahl = 0!) 

(LSB) 

Angaben zum Sektorformat 

12-13 

(MSB) 


Bytes pro Sektor 



(LSB) 

14-15 

(MSB) 


Interleave 



(LSB) 

16-17 

(MSB) 


Track Skew Faktor 


(LSB) 

18-19 

(MSB) 


Zylinder Skew Faktor 


(LSB) 

Angaben zum Plattentyp 

20 

SSEC | 

HSEC 

| RMB 

TZ 

Reserviert 

. 

21-23 

Reserviert 


Track Skew Faktor Anzahl phys. Sektoren zwischen dem letzten log. Block einer Spur 
und dem ersten log. Block auf der direkt anschließenden Spur. 

Zylinder Skew Faktor Anzahl phys. Sektoren zwischen dem letzten log. Block eines Zylin¬ 
ders und dem ersten log. Block auf dem direkt anschließenden Zylin¬ 
der. 


SSEC 


Soft Sectored. Bei gesetztem Bit ist die Platte softsektoriert. Bit 
HSEC muß dann gelöscht sein! 


HSEC 


Hard Sectored. Bei gesetztemBithandeltes sich umeinehardsektorier- 
te Platte. Dann muß das SSEC-Bit gelöscht sein! 


RMB 


Removable. Bei Wechselplatten ist dieses Bit gesetzt, sonst gelöscht. 


Viele dieser Angaben sind Read-Only-Daten, d. h., sie werden wohl beim MODE SENSE- 
Kommando geliefert, können aber nicht geändert werden. Außerdem gilt hier die Regel, daß 
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in dieser Page gemachte Einstellungen erst nach einem unmittelbar folgenden FORMAT 
UNIT-Befehl gültig werden! 

MODE SENSE 

Dieser Befehl ist das Gegenstück zum MODE SELECT-Befehl. Mit ihm lassen sich die 
Einstellungen des Peripheriegerätes vom Initiator einlesen. 

MODE SENSE (OP-Code IAH) 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

0 

0 

0 

1 

1 

0 

1 

0 

1 

Logical Unit 

Reserviert 

2 

PCF 

Page Code 

3 

Reserviert 

4 

Transferlänge 

5 

Herstellerspez, 

Reserviert 

Flag 

Link 


PCF Page Control Field. Mit diesen beiden Bits läßt sich festlegen, welche Art von 

Page-Parametern zurückgeliefert werden soll. 

PCF - 00: Report Cunent Values. Die im Moment eingestellten Parameter 
sollen zurückgeliefert werden. Das sind entweder jene Parameter, die durch 
den letzten, erfolgreich durchgeführten MODE SELECT-Befehl eingestellt 
wurden, oder gespeicherte Werte (Saved Parameter), weil seit dem Einschal¬ 
ten des Geräts noch kein MODE SELECT-Befehl ausgeführt wurde. 

PCF ~ 01: Report Changeable Values. Es wird in den angeforderten Pages 
lediglich durch gesetzte Bits signalisiert, welche Parameter änderbar sind. 
Nicht änderbare Bits oder Felder werden mit 0 zurückgegeben. 

PCF = 10: Report Default Values. Angeforderte Pages werden mit den 
Standardeinstellungen ab Werk zurückgeliefert. 

PCF -11: Report Saved Values. Die angeforderten Pages werden mit den 
zuletzt gespeicherten Einstellungen zurückgegeben. 

Page Code In diesem Feld ist anzugeben, welche Page zurückgeliefert werden soll. Sollen 

alle Pages geliefert werden, ist hier 3F H einzutragen. 
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Transferlänge Anzahl der Bytes, die der Initiator bei der auf dieses Kommando folgenden 

DATA IN-Phase aufnehmen kann. Das Target liefert so lange Daten, bis 
diese Länge erreicht ist oder bis im Target keine weiteren Daten mehr vor¬ 
liegen. 


MODESENSE-Daten 


Bit 

Byte 

7 

6 5 4 3 2 1 0 

0 

Anzahl Sense-Daten 

1 

Medium-Typ 

2 

WP 

Reserviert 

3 

Blockdeskriptor-Länge (=8) 

BlockdeskrivtoH en ) 

0 

Density Code 

1-3 

(MSB) Blockanzahl (LSB) 

4 

Reserviert 

wm 

(MSB) Blocklänee (LSB) 


WP steht für Write Protected und signalisiert mit einem gesetzten Bit, daß das Medium 
schreibgeschützt ist. 

Medium-Typ, Density Code, Blockamahl und Blocklänge enthalten die gleichen Angaben, 
wie bereits beim MODE SELECT-Kommando erläutert. 

Die mit der auf dieses Kom m ando folgenden DATA IN-Phase eingelesenen Daten sind 
ebenfalls wieder Page-strukturiert. 

Der Aufbau dieser Pages ist im Prinzip der gleiche, wie beim MODE SELECT-Kommando 
bereits beschrieben. Lediglich die beiden obersten Bits im jeweils ersten Page-Code Byte sind 
reserviert. 

Das höchstwertige dieser beiden Bits wird manchmal benutzt, um anzuzeigen, ob die 
Parameter in der Page auch dauerhaft gespeichert werden können. 

Da die Page 4 Parameter zur “Geometry” einer Platte enthält und somit einiges an Informa¬ 
tionen über die Platte liefert, soll der Aufbau dieser Page (die nur gelesen werden kann!) hier 
noch kurz gezeigt werden. 
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Unveränderbare Plattenparameter (Disk Geometry) Page 04 H 


Bit 

Byte 

7 | 6 

5 4 3 2 1 0 

0 

Reserviert 

Page Code (= 04„) 

1 

Page-Länge (üblicherweise 12 H ) 

2-4 

(MSB) Anzahl Zylinder (LSB) 

5 

Anzahl Köpfe 

6-8 

(MSB) Startzyl. mit Schreibvorkompensation (LSB) 

9-11 

(MSB) Startzyl. mit reduz. Schreibstrom (LSB) 

12-13 

(MSB) Steprate (LSB) 

14-16 

(MSB) Zylindemummer der Ladezone (LSB) 

17-19 

Reserviert 


START/STOP UNIT 

Mit diesem Kommando ist es möglich, eine LUN des Targets “Ein” und “Aus” zu schalten. 

Bei Platten ist es so möglich, diese mit dem STOP UNIT-Befehl in eine Art Ruhezustand zu 
versetzen, in dem sie wenig Strom verbrauchen und auch entsprechend weniger Geräusche 
verursachen. 

Platten ohne Autopark-Funktion (heutzutage selten zu finden) lassen sich mit diesem Befehl 
in eine Art Transportstellung bringen, so daß sie nicht mehr so empfindlich auf Erschütterun¬ 
gen reagieren. 


START/STOP UNIT (OP-Code 1B„) 


Bit 

Byte 

7 

T 

s 

4 

3 

2 

TH 

0 

0 

0 

0 

0 

1 

1 

0 

1 

1 

1 

Logical Unit Reserviert 

IMMED 

2 

Reserviert 

3 

Reserviert 

4 

Reserviert 

START 

5 

Herstellerspez. Reserviert 

Flag 

Link 
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IMMED Bei gesetztem Bit wird direkt nach Einleitung der Aktion (Start oder Stop) das 

Statusbyte zurückgegeben. Bei gelöschtem Bit wird der Status erst geliefert, 
wenn das Kommando beendet ist. 

START Ein gesetztes Bit bedeutet “START”. Bei gelöschtem Bit wird gestoppt! 

PREVENT/ALLOW MEDIUM REMOVAL 

Dieses Kommando existiert natürlich nur für Peripheriegeräte mit Wechselmedien, wie z. B. 
Wechselplatten. Mit diesem Kommando läßt sich eine Ver-/Entriegelung des Mediums vor¬ 
nehmen. Damit kann z. B. bei entsprechender Implementation der Systemsoftware ein nicht 
zulässiger Mediumwechsel verhindert werden. 


PREVENT/ALLOW MEDIUM REMOVAL (OP-Code 1E H ) 


Bit 

Byte 

7 

6 

5 

4 

3 

~--- 

2 

1 

0 

0 

0 

0 

0 

1 

1 

, 1 

1 

0 

1 

Logical Unit 

Reserviert 

2 

Reserviert 

3 

Reserviert 

4 

Reserviert 

PREVENT 

5 

I-Ierstellerspez. Reserviert 

Flag 

Link 


PREVENT Bei gesetztem Bit ist ein Mediumwechsel gesperrt, sonst zulässig! Nach einem 
Reset ist eine evtl. Verriegelung jedoch wieder aufgehoben! 

Doch nun zum praktischen Umgang mit den SCSI-Informationen in Verbindung mit dem TT. 


Das SCSI-Interface beim TT 

ATARI verwendet im TT für die Bedienung des SCSI-Ports einen alteingeführten Controller- 
Chip, den “5380”. Alle erforderlichen Komponenten für das Betreiben eines SCSI-Ports sind 
in diesem Chip enthalten. 

So ist der Chip durch entsprechende Ausgangsstufen in der Lage, direkt den SCSI-Bus zu 
treiben. Bis zu 48mA bei einem Low-Pegel von 0,5 V “verkraftet” der Chip pro Ausgang ohne 
zusätzliche Treiber-Chips. 
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Abh. 6.2: Die SCSi-Hardware des TT 
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Nur durch Softwareeinstellung ist der 5380 sowohl als Initiator als auch als Target betreibbar. 
ARBITRATION und RESELECTION sind möglich (aber z. Zt. nicht verwendet). 

Der 5380 kann in DMA-Umgebungen verwendet werden, wobei er im TT durch einen eigenen 
SCSI-DMA-Controller (bestehend aus zwei Custom-Chips) unterstützt wird. Eine Transferrate 
bis zu 1,5 MByte/s im Asynchronbetrieb (Synchronbetrieb kann der Chip nicht!) ist zu errei¬ 
chen. 

Natürlich kann der 5380 auch einige Interrupts erzeugen. Folgende Interrupts sind möglich: 
SELECTION/RESELECTION,SCSI-Bus-Reset,Parity-Fehlerwährendeines Datentransfers, 
SCSI-Bus-DISCONNECTION, Ende des DMA-Transfers oder bei unzulässigenBuszuständen 
während einer Busphase. Ausgenutzt wird die Interruptfähigkeit des 5380 im TT jedoch nicht. 
Sein Interrupt-Ausgang IRQ wird lediglich bei manchen Aktionen per Polling abgefragt (Bit 
7 des I/O-Ports vorn TT-MFP, Adr. $FF FA81, “GPIP_TT”). 


Die Register des SCSI-Controllers 

Der 5380 wird als Peripheriebaustein in Form von acht Registern mit einer Registerbreite von 
8 Bit angesprochen. Dabei liegt im TT der 5380 mit seinen Registern auf ungeraden Adressen. 
Auch hier gilt wieder, daß diese Adressen sowohl im ST-Adreßraum (24 Bit) bei $FF 878X 
als auch im 32 Bit-Adreßraum der 68030-CPU “ganz oben” bei $FFFF 878X auftauchen. Je 
nachdem, ob auf den 5380 ein Lese- oder Schreibzugriff stattfindet, erfüllen die Register zum 
Teil verschiedene Aufgaben. 


Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 8781 

R 

Aktueller Inhalt des SCSI-Datenbusses 

“s_data” 


Bei einem Lesezugriff auf diese Adresse erhält man die Daten, die sich im Moment auf dem 
SCSI-Datenbus befinden. Wenn mit Parität gearbeitet wird, wird diese immer zu Beginn des 
Lesezyklusses getestet. Verwendet wird dieses Register während eines Lesevorgangs “von 
Hand” oder während der ARBITRATION-Phase zur Überprüfung, ob noch ein höherwertiges 
Device sich um den Bus bemüht. 


Adresse 

Zugriff 

Bezeichnung 

Label 

SFF8781 

W 

Ausgabedaten 

“s_data” 


Bei einem Schreibzugriff findet man an der gleichen Adresse wie zuvor das Register für die 
Daten, die über den Bus gesendet werden sollen. 
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Sowohl während eines normalen Schreibzugriffes durch die CPU auf den SCSI-Bus als auch 
während DMA-Betrieb wird dieses Register für die Datenausgabe verwendet. Außerdem wer¬ 
den während der ARBITRATION- und SELECTION-Phase über dieses Register die ID-Bits 
ausgegeben. 


Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 8783 

R/W 

| Initiator-Befehlsregister 

“s_icr” 


Mit Hilfe dieses Registers lassen sich bestimmte Bussignale im Initiatorbetrieb beeinflussen 
und auch bei einem Lesezugriff auswerten. Der Stand des ARBITRATION-Prozesses läßt sich 
in diesem Register durch entsprechende Bits ebenfalls ablesen. 

Obwohl die meisten dieser Bits nur bei Initiatorbetrieb interessant sind, gibt es doch auch eini¬ 
ge, die für den Betrieb des Chips als Target verwendet werden (was im TT jedoch nicht vor¬ 
kommt!). 


Initiator-Befehlsregister (WRITE) 


Bit 7 

6 

5 

4 

3 

2 

1 

0 

Assert 

Test 


Assert 

Assert 

Assert 

Assert 

Assert 

„RST 

Modus 

0 

_ACK 

_BSY 

_SEL 

_ATN 

Data 
to Bus 


Initiator-Befehlsregister (READ) 


Bit 7 

6 

5 

4 

3 

2 

1 

0 

Assert 

AIP 

LA 

Assert 

Assert 

Assert 

Assert 

Assert 

„RST 



„ACK 

_BSY 

_SEL 

_ATN 

Data 
to Bus 


Bit 7 

Assert _RST (R/W) Aktiviere RESET. 

Solange dieses Bit gesetzt ist, wird auf dem SCSI-Bus die RESET- 
Leitung aktiviert! Mit Einschalten von RESET wird auch der IRQ- 
Ausgang des 5380 aktiviert! Bei einem Lesezugriff wird der Zustand 
dieses Registerbits zurückgeliefert. 
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Bit 6 

Test Modus (W) Nur für Testzwecke gedacht! Im Normalbetrieb muß dieses Bit ge¬ 
löscht sein! 


AIP (R) Arbitration in Progress. Am Zustand dieses Bits kann abgelesen 

werden, ob der Chip sich gerade in einer ARBITRATION-Phase 
befindet. Damit der Chip sich überhaupt an der ARBITRATION- 
Phase beteiligt, muß das ARBITRATE-Bit (Bit 0) im Betriebsarten¬ 
register (sjmode) gesetzt sein. Wenn der Chip sich an der ARBI¬ 
TRATION beteiligt, wird AIP gesetzt, sobald eine BUS FREE-Phase 
erkannt wurde, der 5380_BSY aktiviert hat und seine ID auf den Bus 
gelegt ist. 


Lost Arbitration. Der 5380 hatte sich um den SCSI-Bus bemüht, 
jedoch die ARBITRATION verloren. Damit eine Auswertung des 
LA-Bits möglich ist, muß das ARBITRATE-Bit im Betriebsarten¬ 
register (s_mode) gesetzt sein. 

Bit 4 

Assert _ACK (RAV) Aktiviere _ACK-Ltg. Dieses Bit wird von einem Initiator während 
des Datenaustauschs verwendet, um den _REQ/_ACK-Handshake 
abzuwickeln. Bei gesetztem Bit wird die _ACK-Leitung aktiviert. 
Damitder Handshake funktioniert, muß das TARGETMODE-Bit im 
Betriebsartenregister (s_mode) gelöscht sein. 

Bei einem Lesezugriff erhält man die im Moment gültige Einstellung 
des Registerbits. 

Bit 3 

Assert _BSY (RAV) Aktiviere _BSY-Ltg. Mit diesem Bit wird direkt die _BSY-Ltg. ge¬ 
steuert. 


Bit 5 

LA (R) 


Bei einem Lesezugriff erhält man die im Moment gülüge Einstellung 
des Registerbits. 


Bit 2 

Assert _SEL (RAV) Aktiviere _SEL-Ltg. Direkte Beeinflussung der _SEL-Ltg. 

Bei einem Lesezugriff erhält man die im Moment gültige Einstellung 
des Registerbits. 
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Bit 1 

Assert _ATN (RAV) Aktiviere _ATN-Ltg. Nur wirksam, wenn der 5380 als Initiator 

arbeitet. Dazu muß das TARGETMODE-Bit im Betriebsarten¬ 
register (s_mode) gelöscht sein. 

Bei einem Lesezugriff erhält man die im Moment gültige Ein¬ 
stellung des Registerbits. 


BitO 

Assert Data to Bus (RAV) Bei gesetztem Bit können die Daten im Ausgabedatenregister 

(s_dat) auf den SCSI-Datenbus gelangen. 

Außerdem wird die zugehörige Parität erzeugt und ausgegeben. 

Die Datenbusausgänge des 5380 werden bei Initiatorbetrieb 
jedoch nur dann freigegeben, wenn das TARGETMODE-Bit im 
Betriebsartenregister (s_mode) gelöscht ist, J/O-Signal vom 
Bus deaktiviert ist und die Signale _C/D und _MSG mit den 
entsprechenden Einstellungen im Target-Befehlsregister (s__tcr) 
übereinstimmen, also “in Phase liegen”. 

Dieses Bit sollte bei DMA-Sendebetrieb natürlich ebenfalls 
gesetzt sein! 

Bei einem Lesezugriff erhält man die im Moment gültige 
Einstellung des Registerbits. 


Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 8785 

RAV 

Betriebsartenregister 

“s_mode” 


Mit einem Schreibzugriff lassen sich die einzelnen Betriebsarten des 5380 einstellen. 
Ein Lesezugriff liefert dann die im Moment eingestellte Betriebsart. 


Bit 7 

6 

5 

4 

3 

2 

1 

0 

Block 

Tar- 

Enable 

Enable 

Enable 

Moni- 

DMA 

Arbi- 

Mode 

get- 

Parity 

Parity 

EOP- 

tor 

Mode 

träte 

DMA 

mode 

Check 

Interr. 

Inter. 

Busy 


L 
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Blockmode-DMA 

TARGETMODE 

Enable Parity Checking 

Enable Parity Interrupt 

Enable EOP-Interrupt 

Monitor Busy 

DMA-Mode 

ARBITRATE 


Mit diesem Bit wird die Art des Handshakes zwischen DMA- 
Baustein und 5380-Chip festgelegt. Im TT ist kein Blockmode- 
DMA möglich. Folglich muß bei allen DMA-Operationen das 
Bit gelöscht sein! 

Mit diesem Bit wird festgelegt, ob der 5380 als Initiator 
(Bit = 0) oder als Target (Bit = 1) arbeiten soll! 

Bei gesetztem Bit werden Paritätsfehler signalisiert. Wenn 
Paritätsfehler aufgetreten sind, wird dies in Form eines gesetz¬ 
ten Bit 5 im Statusregister angezeigt. 

Bei gesetztem Bit wird bei einem Paritätsfehler ein entspre¬ 
chender Interrupt ausgelöst. Dazu muß natürlich auch das 
“Enable Parity Checking”-Bit gesetzt sein! 

EOP steht für End of Process. Bei gesetztem Bit reagiert der 
5380 damit auf das EOP-Signal vom DMA-Baustein, der damit 
das Ende eines DMA-Prozesses signalisiert. Es wird bei ge¬ 
setztem Bit dann ein entsprechender Interrupt ausgelöst. 

Bei gesetztem Bit wird die _BSY-Leitung des SCSI-Busses 
überwacht und bei unerwartetem Deaktivieren von Busy ein 
Interrupt ausgelöst. Wenn das geschieht, werden die untersten 
sechs Bits des Initiator Befehlsregisters (s_icr) gelöscht, und 
der 5380 nimmt alle Signale vom SCSI-Bus herunter! 

Dieses Bit wird benutzt, um einen DMA-Transfer in die Wege 
zu leiten. Es ist dazu vor dem Beschreiben der DMA-Register 
des 5380 zu setzen. Ein DMA-Transfer kann durch Rücksetzen 
dieses Bits abgebrochen werden. Bei einem EOP-Signal vom 
DMA-Baustein wird dieses Bit allerdings nicht zurückgesetzt! 

Durch Setzen dieses Bits wird der 5380 veranlaßt, in die 
ARBITRATION-Phase einzutreten. Dazu muß das Ausgabeda¬ 
tenregister (s_data) die eigene SCSI-Device-ID enthalten. So¬ 
bald der 5380 eine BUS FREE-Phase erkennt, wird der Chip 
versuchen, den Bus “für sich zu gewinnen”! Erfolg oder Miß¬ 
erfolg und auch der Zustand der ARBITRATION kann ja über 
die AIP- und LA-Bits im Initiator-Befehlsregister (s_icr) ermit¬ 
telt werden. 
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Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 8787 | 

R/W 

Target Befehlsregister 

“s_tcr” 


Wenn der 5380 als Target (TARGETMODE-Bit im Betriebsartenregister (s_mode) gesetzt!) 
betrieben wird, erlaubt dieses Register die Kontrolle über die SCSI-Bus-Transferphasen durch 
direktes Steuern der_MSG-, _C/D- und _I/0-Leitungen, 

Außerdem wird über dieses Register die _REQ-Handshakeleitung direkt gesteuert. 


Bei DMA-Betrieb wird durch ein Bit signalisiert, wann das letzte Datenbyte über den SCSI- 
Bus gesendet wurde (nur 53C80-Chip!). 


Bit 7 

6 

5 

4 

3 

2 

1 

0 

Last 

Byte 

Sent 

nicht 

be¬ 

nutzt 

nicht 

be¬ 

nutzt 

nicht 

be¬ 

nutzt 

Assert 

_REQ- 

Assert 

JMSG 

_ 

Assert 

_C/D 

Assert 

_I/0 


Last Byte sent Nur lesbar! Bei gesetztem Bit ist das letzte Byte auf den SCSI-Bus 
gegeben worden. Dieses Flag wird gebraucht, weil das “End of DMA”- 
Bit im Statusregister (s_idstat) lediglich darüber informiert, wann das 
letzte Byte vom DMA-Baustein übergeben wurde! ATARI verwendet 
im TT jedoch noch den 5380-Chip, der dieses Bit noch nicht kennt! 

Wenn der 5380 als Initiator betrieben wird, müssen während eines Datentransfers die Zustande 
der Bits 0..2 mit den Zuständen auf den SCSI-Bus-Leitungen übereinstimmen. Sonst entsteht 
ein Phasen-Mischmasch, äh.., “Phase-mismatch”, der, wenn eingeschaltet, zu einem Interrupt 
führt. Bei Initiatorbetrieb hat das Assert _REQ-Bit keine Funktion! 


Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 8789 

R 

Busstatusregister 

“sjdstat” 


Aus diesem Register können die jeweils aktuellen Zustände der sieben wichtigsten SCSI- 
Steuer-Leitungen abgelesen werden. 

Man erhält dabei jeweils einen “Schnappschuß” der aktuellen Busphase. So kann bei Initia¬ 
torbetrieb z. B. ein _REQ-Signal vom Target an dem entsprechenden Bit erkannt werden. An¬ 
schließend wird das angeforderte Byte ausgegeben und mit _ACK quittiert. 
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Bit 7 

6 

~ 5 

4 

3 

2 

1 

0 

JRST 

JBSY 

JREQ 

_MSG 

_C/D 

J/o 

_SEL 

Parität 


Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 8789 

| W 

Adreßregister 

“sjdstat” 


Dieses Register kann während der SELECTION-Phase benutzt werden. Es ist als Maskenregister 
zu verwenden, in dem das ID-Bit gesetzt wird, auf dessen “Auftauchen” während der 
SELECTION-Phase gewartet wird. Wenn dieses ID-Bit auf dem Bus erkannt wird und zudem 
_BSY deaktiviert und _SEL aktiviert ist, wird ein Interrupt veranlaßt. Wenn auf diesen Inter¬ 
rupt verzichtet werden soll, sind alle Bits in diesem Register auf 0 zu setzen! 


Adresse 

Zugriff 

Bezeichnung 

1 Label 

$FF 878B 

R 

Statusregister 

| “s_dmastat” 


In diesem Statusregister findet man zum einen die SCSI-Bussignale wieder, die im 
Busstatusregister (sjdstal) nicht zu finden sind, und zum anderen sechs weitere Statusbits. 


Bit 7 

6 

5 

4 

3 

2 

1 

0 

End 

of 

DMA 

DMA 

Re¬ 

quest 

Parity 

Error 

IRQ 

aktiv 

Phase 

match 

Busy 

Error 

„ATN 

_ACK 


End of DMA 


DMA Request 


Ende eines DMA-Prozesses. Zurückgesetzt wird dieses Bit, wenn das 
“DMA-Mode”-Bit im Betriebsartregister (s_mode) gelöscht wird. 

Damit kann die CPU den Zustand des DRQ-Anschlusses des 5380 
überwachen. Wird normalerweise nicht benötigt. 


Parity Error Hierüber wird ein Paritatsfehler während eines Datenempfangs oder 

während der SELECTION-Phase mitgeteilt. Natürlich nur dann, 
wenn das “Enable Parity Checking”-Bit im Betriebsartregister 
(s_mode) gesetzt ist. Gelöscht wird diese Fehlermeldung durch 
Auslesen des Resetregisters für Interrupts und Parityfehler (s_inircv). 
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IRQ aktiv 


Phase match 


Busy Error 


Der Zustand des IRQ-Pins des 5380 kann hier zusätzlich abgelesen 
werden. Interrupts werden durch Auslesen des Resetregisters für 
Interrupts und Parityfehler (sjnircv) gelöscht. 

Dieses Bit ist nur für Initiatorbetrieb interessant und enthält eine 
ständige Aussage darüber, ob die unteren 3 Bits des Target-Befehls¬ 
registers (s_tcr) mit den SCSI-Signalen _MSG, _C/D und _I/0 kor¬ 
respondieren. Nur bei einem Phase match ist Datentransfer zulässig. 

Dieses Bit wird aktiviert, wenn JBSY unerwartet inaktiv wird. 


_ATN 


Der Zustand der Attention-Leitung. 


„ACK 


Der Zustand der Acknowledge-Leitung. 


Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 878B 

W 

Start DMA-Ausgabe 

“s_dmastat” 


Bei einem Schreibzugriff auf dieses Register (Wert ist dabei egal!) wird die DMA-Ausgabe 
gestartet. Vorher muß das “DMA-Mode”-Bit im Betriebsartregister (s_mode) gesetzt sein! 

Außerdem sind alle nötigen Einstellungen wie Initiator/Targetbetrieb und “Block-Mode- 
DMA” oder “Normal DMA-Mode” natürlich ebenfalls vorher vorzunehmen. 

Im TT steuert eine eigene SCSI-DMA-Einheit (zwei Custom Chips) den DMA-Betrieb mit 
dem 5380! 


Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 878D 

W 

Start Target-DMA-Eingabe 

“s_targrcv” 


Wenn der 5380 als Target arbeitet, wird für lesenden DMA-Betrieb (vom SCSI-Bus lesen!) 
die Aktion durch einen Schreibzugriff auf dieses Register (Wert egal) gestartet. 


Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 878D 1 

R 

Eingaberegister 

' “s_targrcv” 


Über einen Lesezugriff auf dieses Register erhält man die Daten vom SCSI-Datenbus. Jeweils 
bei Aktivierung von _ACK (bei Target-DMA-Eingabe) oder bei Aktivierung von_REQ (bei 
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Initiator-DMA-Eingabe) wird das Datebyte auf dem SCSI-Bus in diesem Register zwischenge¬ 
speichert (latched). 


Der DMA-Baustein liest die Daten Byte für Byte aus diesem Register aus. Dabei werden die 
_IOR- und _DACK-Anschlüsse entsprechend durch den DMA-Baustein bedient. 


Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 878F 

W 

| Start Initiator-DMA-Eingabe 

“sjnircv’' 


Ein Schreibzugriff (Wert ist egal) startet den lesenden DMA-Betrieb bei Programmierung des 
5380 als Initiator. Für DMA-Betrieb muß natürlich wieder das “DMA-Mode”-Bit im 
Betriebsartregister (s„mode) und der 5380 auf Initiatorbetrieb eingestellt sein. 


Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 878F 

R 

Resetreg. für Interrupts + Parityfehler 

“sjnircv” 


Interrupts und Parity-Fehleranzeigen werden durch Lesen dieses Registers gelöscht. Dabei 
erhält man keinen sinnvollen Wert zurück. Es kommt nur auf den Lesezugriff an! 


Damit’s einfacher wird - SCSI-Datentransfer mit 
DMA-Unterstützung 

Für den Datenaustausch während der Datentransferphasen hat ATARI dem 5380 eine eigene 
DMA-Einheit zur Seite gestellt. Gleiches gilt für den im TT vorhandenen Serial Communications 
Controller SCC. 

Da der 5380 Daten nicht in der auf dem Systembus verwendeten Long-Form (32 Bit-Zugriff) 
verarbeiten kann, ist die DMA-Einheit für die Umsetzung zuständig. Dabei arbeitet der DMA- 
Baustein immer mit zwei Longs. Während also die DMA-Einheit darauf wartet, das eine Long 
auf den Systembus zu geben, wird schon das nächste Long im DMA-Baustein zusammenge¬ 
setzt. Wenn das zweite Long bereits gefüllt sein sollte, bevor der DMA-Baustein die Kontrolle 
über den Systembus wieder abgegeben hat, wird das zweite Long direkt hinterher geschrieben. 

SCSI-DM A-Betrieb ist dabei auf jede RAM-Adresse möglich. Also im Gegensatz zum DMA- 
Betrieb mit ACSI-Geräten gibt es keinerlei Beschränkung auf den Bereich des ST-RAMs. 

Für den Programmierer stellt sich der DMA-Kanal folgendermaßen dar: 



Ein Schritt in die richtige Richtung - Der TT-SCSI-Port 


1125 


- Ein Status- und Control-Register in Word-Breite, auf das schreibend und lesend 
zugegriffen werden kann. 

- Ein 32-Bit-Adreßregister (Pointer) für die DMA-Adresse (liegt in Form von vier 
Registern mit Bytebreite vor). 

- Ein Restdatenregister, welches benutzt wird, um mit CPU-Hilfe Transfers auf nicht im 
Long-Raster (durch 4 teilbare) liegende Adressen zu ermöglichen. Gleiches gilt für 
DMA-Transfers mit Blockgrößen, die nicht im Long-Raster (4-Byte-Raster) liegen. 

- Ein 32-Bit-Bytezähler für DMA-Daten. Dieses Zählregister wird durch Kombination 
von vier Bytes gebildet. 


DieSCSI-DMA-Register 

Die Registeradressen des SCSI-DMA-Chips liegen sowohl am oberenEnde des ST-Adreßraums 
($FF 87XX) als auch ganz oben im TT-Adreßraum ($FFFF 87XX). Angegeben ist hier je¬ 
weils die Lage im ST-Adreßraum! 


Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 8701 

R/W 

DMA-Address-Pointer (Highest Byte) 

“tt_dmabas” 

$FF 8703 

R/W 

DMA-Address-Pointer (High Byte) 

“tt_dmabas”+2 

$FF 8705 

RAV | 

DMA-Address-Pointer (Low Byte) 

“tt_dmabas”+4 

$FF 8707 

RAV 

DMA-Address-Pointer (Lowest Byte) 

“tt_dmabas”+6 

$FF 8709 1 

RAV 

DMA-Bytezähler (Highest Byte) 

“tt„dmacnt” 

$FF 870B 

RAV 

DMA-Bytezähler (High Byte) 

“tt_dmacnt”+2 

$FF 870D 

RAV 

DMA-Bytezähler (Low Byte) 

“tt_dmacnt”+4 

$FF 870F 

RAV 

DMA-Bytezähler (Lowest Byte) 

“tt_dmacnt”+6 


Da diese vier Byte breiten Register alle so schön hintereinanderliegen, kann für den Long- 
Zugriff darauf in Maschinensprache ein “movep.l”-Befehl benutzt werden! 


Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 8710 

R 

Restdatenregister (High-Word) 

“tt_dmarsd” 

$FF 8712 

R 

Restdatenregister (Low-Word) 

“tt_dmarsd”+2 


Wenn am Schluß einer DMA-Operation kein voller Long mehr in den Speicher übertragen 
wurde, muß hier der Rest an Datenbytes “per Hand” ausgelesen und durch die CPU an die 
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richtigen Adressen gebracht werden! Wie viele Restbytes das sind, erfährt man aus den letzten 
beiden Adreßbits des DMA-Address-Pointers. 

Die Startadresse n für die Restbytes ergibt sich aus dem Inhalt des DMA-Address-Pointers 
minus der Anzahl an Restbytes, Die Restbytes sind “linksbündig” im Restdatenregister ange¬ 
ordnet. Also gehört das Highbyte im High-Word an die Startadresse n. Das Lowby te im High- 
word kommt nach Startadresse n+1 usw.! 


Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 8714 

| R/W 

Kontrollregister (Word) 

“tt_dmactl” 


Obwohl dieses Register mit Wordzugriffen bearbeitet wird, sind nur die untersten S Bits 
benutzt. Man kann deshalb auch mit Bytezugriffen auf die Adresse $(FF)FF 8715 arbeiten, 
um diese Kontrollbits zu beeinflussen bzw. auszuwerten. Hier deshalb nur die interessanten 
unteren 8 Bits des Registers: 


Bit 7 

6 

5 

4 

3 

2 

I 

0 

Bus 

Error 

_ 

Byte 

count 

zero 

Reser¬ 

viert 

Reser¬ 

viert 

Reser¬ 

viert 

Reser¬ 

viert 

DMA 

Enable 

DMA- 

Direc¬ 

tion 


Bus Error 


Byte count zero 


DMA-Enable 

DMA-Direction 


Ein gesetztes Bit weist auf einen Busfehler während des DMA- 
Betriebs hin. Durch Auslesen dieses Registers wird der Busfehler- 
Status wieder zurückgesetzt. Diese Fehlersignalisierung geht auch an 
den TT-MFP, I/O-Port #5 und kann bei entsprechender Program¬ 
mierung einen Interrupt auslösen. 

Ein gesetztes Bit zeigt an, daß der DMA-Bytezähler auf Null gezählt 
hat, also alle Bytes transferiert sind. 

Bei gesetztem Bit ist der DMA-Baustein “eingeschaltet”. 

Bit gesetzt: Schreiben an SCSI-Controller. Bit gelöscht: Lesen von 
SCSI-ControIler. 


Um einen DMA-Betrieb durchzuführen, ist zunächst die Transferrichtung im DMA-Baustein 
(Bit 0 in “tt_dmactl”) einzustellen. Anschließend wird die Basisadresse im DMA-Address- 
Pointer (“tt_dmabas”) gesetzt und die Zahl der zu übertragenden Bytes im DMA-Bytezähler 
(“tt_dmacnt”) eingestellt. 
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Wenn dann auch der SCSI-Controller entsprechend programmiert ist, wird durch Setzen des 
“DMA-Enable”-Bits in “tt_dmacü” der DMA-Prozeß gestartet. 


Die Programmierung des TT-SCSI-Ports 

Das nachfolgende Listing zeigt in Form einer kommentierten Beispielroutine den Umgang mit 
der SCSI-Hardware im TT. Der TT arbeitet dabei als Initiator in einer Single-Initiator-Umge- 
bung (also ohne ARBITRATION-Phase) und liest mit dem INQUIRY--Befehl die Daten von 
dem SCSI-Device-#0 in einen Buffer ein. 

Bei diesem Code-Beispiel ist also sowohl die SELECTIONS-Phase, die COMMAND-Phase 
und anschließend eine DATA IN-Phase mit abschließender STATUS- und MESSAGE-Phase 
enthalten. 


; Beispielroutine für die Programmierung des TT-SCSI-Ports 
; von Hans-Dieter Jankowski für ATARI ST/STE/TT Profibuch 


device 

equ 

2 

trlength 

equ 

$A0 

kurz 

equ 

200 

lang 

equ 

400 

bsy da 

equ 

13 

(~250ms) 



__hz_200 

equ 

$4BA 

GPIP_TT 

equ 

$FFFFFA81 

tt_dmabas 

equ 

$FFFF8701 

tt_dmacnt 

equ 

$FFFF8709 

tt draarsd 

equ 

$FFFF8710 

tt_dmactl 

equ 

$FFFF8714 

s_data 

equ 

$FFFF8781 

s icr 

equ 

s data+2 

s_rnode 

equ 

s_data+4 

s_tcr 

equ 

s data+6 


; Target-ID (0 = int. Platte) 
; 160 Bytes Einlesen reicht! 

; Timeout-Wert für 1 Sekunde 
; Timeout-Wert für 2 Sekunden 
; Timeout-Wert f. SELECTION 


; Adr. 200 Hz-Systemtimer 

; TT-MFP Portregister 

; SCSI-DMA-Addreß-Pointer 
; SCSI-DMA-Bytezähler 
; SCSI-DMA-Restdatenbytes 
; SCSI-DMA-Controlregister 

; Erstes Register im 5380 
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s_idstat equ 
s_dmastat equ 
s_targrcv equ 
s jinircv equ 


s_data+8 
s_data+$A 
s_data+$C 
s data+$E 


; Für das SCSI-Device-Nr. "device" werden die INQÜIRY-Daten ein- 
; gelesen 

; Die per DMA gelesenen Daten stehen dann im Speicher ab Adr. 

; "buffer" 

; Bei korrekter Ausführung liefert dO im Low-Word das Statusbyte 
; und im High-Word das MESSAGE-Byte zum Abschluß der Operation. 

; Ein neg. Wert in dO weist auf eine Zeitüberschreitung in be- 
; stimmten Phasen hin. 


inquiry: 
lea 
lea 
lea 


s__data, a5 
tt_dmabas, a6 
_hz_200, a4 


; Ptr. auf 5380-Register setzen 
; Ptr. auf SCSI-DMA-Baustein setzen 
; In a4 Ptr. auf Systemtimer halten 


Erstmal testen, ob der SCSI-Bus zur Zeit frei ist 


move.1 

(a4),d7 

/ 

addi. 1 

#kurz,d7 

r 

bsyO: 


r 

btst 

#6,8(a5) 

7 

beq.s 

doselect 

/ 

crnp.l 

(a4),d7 

r 

bcc.s 

chk bsyO 


moveq 

#-2, dO 

7 

bra 

error 



Aktuellen Systemtimerwert holen 
Bis zu diesem Timerwert versu¬ 
chen. 

_BSY-Leitung testen 
_BSY aktiviert? 

Timerwert mit Endwert vergleichen 
Dauert zu lange, also raus hier. 


Nix mehr los aufm SCSI-Bus! Also dann in die SELECTION-Phase! 

/ 

doselect: 

moveq.l #0,d0 ; 4 Bytes mit Null in Reg. DO! 

movep.l d0,2(a5) ; s_icr/s_mode/s_tcr/s__idstat 

; löschen 

; Target-ID-Bit in s__data einstel- 
; len. 


bset 


#device,(a5) 
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inove.b 

#1,2(a5) 


ID-Bit auf SCSI-Bus ausgeben. 

move.b 

#5,2(a5) 


__SEL-Ltg. aktivieren 

move.1 

(a4),d7 


Aktuellen Systemtimerwert holen 

addi.1 

#bsy__da, d7 


In 250ms muß Targ. sich melden 

chk bsyl: 




btst 

#6,8(a5) 


_BSY~Leitung testen 

bne.s 

docmnd 


_BSY aktiviert? 

cmp.l 

(a4),d7 


Timerwert mit Endwert vergleichen 

bcc.s 

chk bsyl 


Dauert zu lange, also raus hier. 

moveq 

#-3,d0 



bra 

error 



f 

Target hat 

sich gemeldet 

(BUSY ist aktiviert worden). Also ab 

; in die COMMAND-Phase. 



r 

docmnd: 




move.b 

#0,2 (a5) 

} 

Initiator deaktiviert alle Ltg, 

move.w 

#0,tt_dmactl 

} 

DMA-Baust. auf Lesen einstellen 

move.1 

#buffer, dO 

r 

Anfangsadr. des DMA-Puffers in 

movep.1 

dö, (a6) 

f 

DMA-Address-Ptr. ablegen 

move.1 

#trlength,dO 

r 

Transferlänge in 

movep.1 

dO,8(a6) 

r 

DMA-Bytezähler ablegen 


DMA-Baustein ist vorbereitetJetzt "per Hand" die Command- 
Bytes ans Target übermitteln. Dabei wird der _REQ/_ACK- 
Handshake unter CPU-Kontrolle erledigt! 

Die Aktion sollte nicht länger als "kurz" x 5ms dauern, sonst 
Abbruch und Sprung in die Fehlerroutine. 


lea 

cmdtable,aO 

f 

f 

Ptr. auf 1. Byte vom SCSI- 
Kommando 

moveq 

#5, dl 

r 

(Anzahl-1) der zu sendenden Bytes 

move.1 

(a4),d7 

r 

Akt. Sys-Timerwert holen und End¬ 

addi.1 

#kurz,d7 

r 

wert berechnen (steht in d7) 

move.b 

#2,6 (a5) 

r 

"Assert C/D" in s_tcr (CMD- 



r 

Phase!) 

move.b 

#1,2(a5) 

r 

"Assert Data to Bus" in s_icr 







1130 


ATARI Profibuch 


sndcmd: 


bsr 

w4reqa 


Auf REQ-Aktivierung warten 

bpl.s 

gotreq 

r 

REQ aktiviert? 

moveq 

#-4, dO 

/ 

Nein! 

bra 

error 

t 

Dann raus hier! 

gotreq: 




move.b 

(a0) +, (a5) 

} 

Command-Byte auf SCSI-Bus legen. 

bset 

#4,2(a5) 

} 

ACK aktivieren (Bit 4 in s icr) 

bsr 

w4reqd 

/ 

Auf REQ~Deaktivierung warten 

bpl.s 

nxtbyte 

/ 

REQ wieder deaktiviert? 

moveq 

#-5, dO 

/ 

Nein! 

bra 

error 

/ 

Dann raus hier! 

nxtbyte: 




bclr.b 

#4,2(a5) 

f 

Target hat Byte! _ACK 



r 

deaktivieren! 

dbra 

dl, sndcmd 

} 

Schleife, bis alle Bytes raus 



J 

sind! 

move. b 

#0,2 (a5) 

f 

Initiator deaktiviert alle Ltg. 

/ 

,— Command- 

-Descriptor-Block wurde erfolgreich übertragen! 

; Jetzt wird auf DMA-Betrieb geschaltet, und das Target 

; übernimmt die Steuerung der DATA IN-Phase. 

/ 

move.b 

#l,6(a5) 

r 

"Assert _I/0" in s_tcr (DATA IN!) 

tst .b 

14(a5) 

f 

RESET Int.+Parity-Fehler 



/ 

(s inircv) 

move.b 

#2,4(a5) 

/ 

"DMA-Mode" in s_mode einstellen 

move.w 

#2,tt_dmactl 

/ 

DMA-Baustein freigeben (DMA 



/ 

Enable) 

move. b 

#0,14(a5) 

/ 

Start Initiator-DMA-Eingabe! 


Nun müssen wir uns in Geduld fassen, bis die DMA-Phase 
beendet ist. Dazu wird gewartet, bis der 5380 einen IRQ an 
den TT-MFP gibt. Da alle anderen Interrupts des 5380 ausge¬ 
schaltet sind, kann es sich bei einem 5380-Interrupt nur um 
die "Fertigmeldung" des 5380 handeln! 

move.l <a4),d7 ; Akt. Sys-Timerwert holen und End- 

addi.l #lang,d7 ; wert berechnen (steht in d7) 
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wait4int: 

btst #7,GPIP TT 


bne.s 

scsint 

btst 

#5,GPIPJTT 

beq.s 

dmaint 

cmp. 1 

<a4) ,d7 

bcc.s 

wait4int 

moveq 

#-6,d0 

bra 

error 

dmaint: 

btst 

#7, tt_dmactl+l 

beq.s 

wait4int 

moveq 

#-7,d0 

bra 

error 

scsint: 


tst.b 

14(a5) 

moveq.1 

#0,d0 

move.w 

d0,tt_dmactl 

move.b 

dO,4(a5) 

move.b 

d0,2(a5) 

t 

Jetzt wird das Statusbyte 

; Da evtl 

ein MESSAGE-Byte 

; MESSAGE 

IN-Phase gewartet 

t 

move.1 

(a4),d7 

addi.1 

#kurz,d7 

move.b 

#3,6(a5) 

bsr 

w4reqa 

bpl.s 

getstat 

moveq 

#-8,d0 

bra 

error 

getstat: 

move.b 

(a5),d0 

bset 

#4,2(a5) 


; Auf Int. vom 5380 oder DMA- 
; Baustein 

; warten. Dabei Zeitlimit im Auge 
; behalten! 


; Zeitüberschreitung! Raus hier! 

; Bus error-Bit testen! 

; Bus error bei DMA aufgetreten? 


; DMA-Baustein ausschalten 
; 5380 aus DMA-Betrieb holen 
; (s_mode) 

; Alle SCSI-Ltg. deaktivieren 
; (s__icr) 

vom Target geholt. 

folgt, wird anschließend auf die 

und das MESSAGE-Byte eingelesen! 

; Akt. Sys-Timerwert holen und End- 
; wert berechnen (steht in d7) 

; _C/D + _I/0 aktivieren (s_tcr) 

; __REQ vom Target abwarten 
; _REQ aktiviert? 

; Nein! 

; Dann raus hier! 


; Statusbyte (s_data) nach dO 
; holen. 

; ACK aktivieren (s icr) . 


; Ja! Dann aber raus hier! 

; RESET Int.+Parity-Fehler 
; (s inircv) 
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bsr 

w4reqd 

REQ-Deaktivierung abwarten 


bpl.s 

getmsg 

REQ deaktiviert? 


moveq 

#-9, dO 

Nein! 


bra 

error 

Dann raus hier! 

t 

t 

Jetzt wird auf die MESSAGE 

IN-Phase gewartet und das 

t 

MESSAGE-Byte eingelesen! 


r 

getmsg: 




move.b 

#0,2(a5) 

Alle Initiatorltg. deaktivieren 


move.b 

#7, 6(a5) 

MSG, C/D und I/O sind bei 

w4msg: 




btst 

#3, 8(a5) 

der MESSAGE IN-Phase aktiviert! 


bne. s 

msg in 

MESSAGE IN-Phase erreicht? 


cmp. 1 

(a4),d7 

Noch nicht! Zeitüberwachung! 


bcc.s 

w4msg 

Zeitüberschreitung? 


moveq 

#-10,dO 

Ja! 


bra 

error 

Dann raus hier! 

msg_ 

in: 




bsr 

w4reqa 

_REQ-Aktivierung testen 


bpi. s 

hole msg 

REQ aktiviert? 


moveq 

#-11,dO 

Nein! 


bra 

error 

Dann raus hier! 

hole_msg: 




swap 

dO 

Statusbyte ins High-Word swappen 


move.b 

(a5) ,d0 

MESSAGE-Byte ins Low-Word holen 


swap 

dO 

Statusbyte wieder ins Low-Word 


bset 

#4,2(a5) 

ACK aktivieren (s icr). 


bsr 

w4reqd 

Warten, bis REQ deaktiviert ist 


bpi. s 

dasjwars 

_REQ deaktiviert? 


moveq 

#-12, dO 

Nein! 


bra 

error 

Dann raus hier! 

das_ 

wars: 




move.b 

#0,2(a5) 

Initiator deaktiviert alle Ltg. 


Wenn der DMA-Transfer nicht auf einer Long-Grenze endete, 
befinden sich im DMA-Restdatenreg. noch ein paar Bytes, die 
"von Hand" in den Bufferspeicher gebracht werden müssen! 
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ende: 


movep.1 

(a6),dl 

f 

Aktuell. DMA-Adr.-Ptr. holen 

move.1 

dl,d2 

t 

Kopie davon in d2 

andi.w 

#3,d2 

r 

Anzahl Bytes im Restdatenregister 

beq.s 

ende 

r 

Keine (Transf. auf Long-Grenze)? 

subq.w 

#l,d2 

f 

Doch! Einen weniger wg. Schleife! 

andi .b 

#$FC,dl 

t 

Letzte Long-Grenze ansteuern. 

move.1 

dl,aO 

T 

Zielpointer in aO 

lea 

tt dmarsd,al 

f 

Quellptr. (Restreg.) nach al 

oop: 




move.b 

(al)+, (aO) + 

/ 

Restliche Bytes aus Restdatenreg. 

dbra 

d2,restloop 

r 

in den Buffer übertragen. 

bra 

ende 






Bei irgendeinem Fehler wird 

zur Sicherheit ein RESET auf 

dem SCSI 

-Bus ausgeführt! 



move.1 

<a4) ,d7 

/ 

Akt. Sys-Timerwert holen und End¬ 

addi.l 

#kurz,d7 

/ 

wert berechnen (steht in d7) 

move.b 

#$80,2(a5) 

t 

RST-Ltg. aktivieren 

cmp.l 

(a4),d7 

f 

Timerende testen 

bcc. s 

waitl 

r 

Timer abgelaufen? 

move.b 

#0,2 (a5) 

r 

Ja! Dann RST-Ltg. deaktivieren 

move.1 

(a4),d7 

r 

Akt. Sys-Timerwert holen und End¬ 

addi.1 

#kurz,d7 

r 

wert berechnen (steht in d7) 

cmp.l 

<a4),d7 

r 

Timerende testen 

bcc.s 

wait2 

i 

Timer abgelaufen? 

rts 





;- Unterprogramm: Warten auf die Aktivierung von _REQ- 


In: d7.1 = 

a4.1 = 
Out: dO = 


Timerendwert 
Pointer auf _hz_200 
0 : Alles klar! _REQ ist aktiviert 

-1 : Zeitüberschreitung 
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w4reqa: 


moveq 

#0, dO 

btst 

#5, 8 (a5) 

bne.s 

gtrqend 

cmp. 1 

(a4),d7 

bcc. s 

w4reqa 

bra. s 

gtrqerr 


; Default ist kein Timeout! 

; _REQ-Ltg. überwachen. 

; _REQ vom Target aktiviert? 
; Nein! Zeitüberwachung! 

; Zeitüberschreitung? 


.- Unterprogramm: Warten auf die Deaktivierung von _REQ — 


In: d7.1 = Timerendwert 


r 

a4.1 

= Pointer auf hz 200 

r 

Out: dO 

= 0 

Alles klar! REQ ist aktiviert 

r 


-1 

Zeitüberschreitung 

w4reqd: 




moveq 

#0,d0 

; Default ist kein Timeout! 


btst 

#5,8{a5) 

; REQ-Ltg. überwachen. 


beq. s 

gtrqend 

; _REQ vom Target deaktiviert? 


cmp.l 

(a4),d7 

; Nein! Zeitüberwachung! 


bcc.s 

w4reqd 

; Zeitüberschreitung? 

gtrqerr: 




moveq 

#-l,d0 

; Ja! Mit -1 in dO raus 


gtrqend: 
rts 


.data 

t 

;-Hier folgt der komplette Command-Descriptor-Block (6-Byte-CDB) 


cmdtable: 

dc.b 

$12 

; Inqiry-Befehl 

dc.b 

$00 

; LUN = 0 

dc.b 

$00 


dc.b 

$00 

; Reserved Bytes 

dc.b 

trlength 

; max. Transferlänge 

dc.b 

$00 

; Kein Linked Command! 

.bss 




;- In den folgenden Puffer werden die INQUIRY-Daten eingelesen 

buffer: 

ds.w 


$100 


; 256-Bytes Puffer reicht aus! 
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Kapitel 7: Seriell, aber schnell! - 
Der SCC macht’s möglich 

Im Zeitalter der schnellen Kommunikation wollte wohl auch ATARI seine neuen Maschinen 
(TT und MEGA STE) bei den Kommunikationsschnittstellen etwas aufwerten. So findet sich 
dann auch im TT (und MEGA STE) ein eigener Schnittstellen-Steuerbaustein vom Typ 85C30 
wieder. Dieser Serial Communications Controller (kurz SCC) übernimmt eine ganze Menge 
Steuerungsaufgaben, wenn es um den Austausch von seriellen Daten geht. 

Der SCC besitzt zwei voneinander unabhängige duplexfähige Kanäle, die im TT sogar durch 
einen eigenen DMA-Chipsatz (gleiche Bausteine wie beim SCSI-DMA-Chipsatz) für schnel¬ 
len Datentransfer unterstützt werden. Die beiden Kanäle erlauben die Realisierung von 
Multiprotokoll-Schnittstellen für die gängigsten Datenübertragungsteuerungsverfahren. 

Dabei besitzt der SCC für jeden Kanal einen eigenen Baudratengenerator, mit dem im asyn¬ 
chronen Start/Stop-Betriebbis zu 250 KBit/s möglich sind (im TT nur 125 KBit/s!). Im Start/ 
Stop-Verfahren können 5..8 Bit-Zeichen mit 1/1,5 oder zwei Stop-Bits und optionaler Erzeu¬ 
gung/Auswertung eines Paritätsbits verwendet werden. 

Im Synchronbetrieb (verbundene Computer sind durch Mitübertragung der Taktsignale 
immer bitsynchron!) erlaubt der SCC DÜ-Raten bis zu 4 MBit/s, wobei aber durch einen 
Primärtakt PCLK im TT von 8 MHZ “nur” maximal 2 MBit/s erreichbar sind. Wenn im Syn¬ 
chronbetrieb die Taktsignale nicht mitübertragen werden, kann der SCC durch eine Digital 
Phase Locked Loop-Einheit (DPLL) aus den Datenflanken der empfangenen Bits den Takt re¬ 
konstruieren und damit die einlaufenden Daten abtasten als auch diesen Takt für das Aussen¬ 
den der eigenen Sendedaten verwenden. Dazu braucht der DPLL einen Takt, der bei der 16fa- 
chen bzw. 32fachen Baudrate der Empfangsdaten liegt. Im TT liegt die realisierbare DÜ-Rate 
wegen der höchstmöglichen Taktfrequenz für den SCC von 8 MHz bei max 125 KBit/s. 


Vom SCC unterstützte Datenübermittlungs- 
Steuerungsverfahren 

Diese Steuerungsverfahren regeln unter anderem die Organisation des Datenflusses während 
der Datenaustausch-Phase. Da es hierbei unter anderem zur Blockbildung der zu übermitteln¬ 
den Daten kommt und Sicherungsinformationen zur Fehlererkennung durch die Gegen¬ 
station eingefügt werden, kann ein Teil dieser Aktionen durch den Schnittstellenbaustein des 
Computers erledigt werden. 
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Asynchrone Steuerungsverfahren 

Das am häufigsten verwendete asynchrone Steuerungsverfahren ist das Start/Stop-Verfahren. 
Dabei wird jedes Zeichen (beim SCC 5..8 Bit plus evtl. Paritätsbit) als eine Einheit (Block) 
betrachtet. Zwischen den einzelnen übermittelten Zeichen können unterschiedlich lange 
Ruhepausen auftreten. 


-Ein Zeichen -► 

, DRTR + Pari tu ST 

3P ff ff 

^ k ■>••• 22ESEZ 

ll II 

STfiRT 


Abb. 7.1: Das Start-IStop-Verfahren 


Im Ruhezustand befindet sich die Sendedatenleitung auf log. 1. Sobald ein Zeichen gesendet 
werden soll, wird für eine vereinbarte Zeit (Einheitsschrittdauer. Anzahl der Einheitsschritte 
je Sekunde ergibt die Baudrate!) eine log. 0 ausgegeben. Auf diesen Startschritt folgen dann 
die eigentlichen Informationsschritte eines Zeichens plus evtl, einer Paritätsinformation (da 
hier ausschließlich Signale mit zwei Kennzuständen, log. 1 und log. 0, betrachtet werden, 
kann man auch für Schritt gleich Bit setzen!). Die Abtastung der Empfangsdatenleitung erfolgt 
sinnvollerweise jeweils in Bitmitte. Dazu erzeugt sich der Empfänger Abtastsignale aus einer 
eigenen Taktquelle, die ein Vielfaches der Datenübertragungsrate beträgt (meistens löfache 
Datenrate). Die Abtastung wird jeweils durch den Startschritt neu gestartet! 

Nach Übermittlung aller Datenbits eines Zeichens geht die Sendedatenleitungen für eine 
vereinbarte Mindestdauer wieder in den Ruhezustand log. 1, bevor das nächste Zeichen (wie¬ 
der mit einem Startbit beginnend) ausgesendet werden darf. Diese Mindestdauer für den Ruhe¬ 
zustand zwischen zwei Zeichen (in Bitlängen ausgedrückt) beträgt mindestens 1 Stopbit. Der 
SCC kann auf 1, 1,5 oder 2 Stopbits eingestellt werden. 


Synchrone Steuerungsverfahren 

Bei der Verwendung von Steuerungsverfahren für synchrone Übertragung ist gewährleistet, 
daß Taktinformationen zusammen mit den Daten übermittelt werden oder daß bei Verwen¬ 
dung von Modemverfahren zur Datenübermittlung der Takt im Modulationsprozeß mit 
“eingepackf ’ wird. So kann also davon ausgegangen werden, daß Bitsynchronismus zwischen 
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den beteiligten Endstellen besteht. Der Empfänger kann anhand des mitgelieferten Takts die 
sichere Abtastung der Bitinformation vornehmen. 

Wenn die Bitsynchronität besteht, muß in der nächsten Phase der Zeichensynchronismus 
hergestellt werden. Das heißt, daß der Empfänger herausfinden muß, wie die einzelnen emp¬ 
fangenen Bits zu Gruppen (Zeichen) zusammenzufassen sind. Dazu hat der Empfänger den 
einlaufenden Bitstrom auf charakteristische Synchronisierzeichen zu untersuchen. 


Zeichenorientierte Steuerungsverfahren 

Hierbei werden Daten in Zeichenblöcken (üblicherweise Textinformation) zusammengefaßt 
und übertragen. Jeder Textblock wird durch ein oder mehrere 8 oder 16 Bit-Synchronzeichen 
eingeleitet. “Umrahmt” sind Textblöcke durch Steuerzeichen, welche den Beginn (STX = 
Start of Text) und das Ende (ETX = End of Text) des Informationsblocks kenntlich machen. 

Meistens werden die übermittelten Blöcke noch um Prüfzeichen ergänzt, die durch spezielle 
Sicherungsverfahren gebildet werden. Anhand dieser Prüfzeichen und einer auf gleiche Weise 
im Empfänger durchgeführten Prüfung können Fehler in der Übertragung erkannt und eine 
Blockwiederholung veranlaßt werden. Dabei wird sowohl das Längsparitätsverfahren (über 
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Abb. 72: Zeichenorientierte Steuerungsverfahren 
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alle Bits gleicher Wertigkeit eines Textblocks wird jeweils ein Paritätsbit gebildet und die Zu¬ 
sammenfassung aller so gewonnenen Paritätsbits als Blockpriifzeichen mitübertragen) als 
auch das CRC-Verfahren verwendet (“Berechnung” einer 16-Bit-Prüfbitfolge aus allen Bits 
des Textblocks und Anhängen an den Datenblock in Form von zwei 8 Bit-Zeichen), Der SCC 
kann die Prüfzeichen nach dem CRC-Verfahren nach zwei verschiedenen “Berechnungsregeln” 
(CRC-16 und CRC-CCITT) ermitteln und auswerten. 

Zeichenorientierte Steuerungsverfahren arbeiten vom Prinzip her nur halbduplex, auch wenn 
die Übertragungsstrecke und die beteiligten Datenstationen duplexfähig sind. Es ist nämlich 
jeweils nach Aussenden eines Textblocks eine Quittung von der Gegenstelle erforderlich, 
bevor der nächste Block gesendet wird. Eine weitere Einschränkung besteht darin, daß 
üblicherweise eine Codebindung besteht. Außerdem werden sowohl die Textinformationen 
als auch die Steuerzeichen aus dem gleichen Code benutzt, so daß normalerweise im Text kei¬ 
ne Steuerzeichen Vorkommen dürfen! Es gibt allerdings Ausnahmen, indem durch ein speziel¬ 
les Zeichen (als Data Link Escape = DLE bezeichnet) die Steuerzeichen als solche kenntlich 
gemacht werden. 


Bitorientierte Steuerungsverfahren 

Auch hier werden die Daten zu Blocks zusammengefaßt. Dabei ist aber keinerlei Bindung an 
einen bestimmten Code erforderlich, sondern es wird mit Bitblöcken gearbeitet. Die weitver¬ 
breiteten Steuerungsverfahren SDLC/HDLC (SDLC = Synchronous Data Link Control von 
1B M/ HDLC=High-Level Data Link Control, vom CCITT empfohlen) verwenden zum Infor¬ 
mationsaustausch einen standardisierten Blockaufbau, den Frame. Die Unterschiede zwi¬ 
schen SDLC und HDLC sind von geringer Natur und bestehen aus Abweichungen in der Be¬ 
handlung einiger Bits im Adress- und Control-Feld. 


Fr» am ft 

n n driL — * 

Flag 

Hdr 

Ctrl. 

Datenfeld nit 

CRC 

Flag 


Feld 

Feld 

beliebiger Zahl 




S Bit 

S Bi t 

von Datenbits 

16 Bit 

S Ei t 


SDLC/HDLC-Fornat 


Abb. 7.3: Bitorientierte Steuerungsverfahren 
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Der Unterschied eines Steuer-/Meldeframes zu einem Informationsframe besteht lediglich 
darin, daß Steuer- und Meldeframes kein Datenfeld beinhalten. 

Jeder Frame beginnt mit einem FLAG. Dafür wird die 8-Bitfolge 01111110 bta = 7E hw verwen¬ 
det. Der Empfänger “rastet” seine Synchronisierung auf diese Bitfolge ein. Da ja alle Bitmu¬ 
ster bei diesem Verfahren z. B. auch im Datenfeld verwendet werden dürfen, muß der Sender 
dafür sorgen, daß die FLAG-Sequenz nicht im eigentlichen Datenstrom auftaucht. Vom Sen¬ 
der wird daher immer nach fünf “1”-Bits automatisch ein “0”-Bit in den Datenstrom eingefügt 
(außer beim FLAG!). Der Empfänger muß dann zwischen dem Start-FLAG und dem End- 
FLAG eines Frames diese “0”-Bits wieder entfernen. 

Bei SDLC/HDLC wird zur Blocksicherung das CRC-Verfahren angewendet und die “berech¬ 
nete” CRC-Bitfolge in Form von 16-Bits unmittelbar vor dem End-FLAG mitübertragen. 

Mit SDLC/HDLC-Steuerungsverfahren ist Duplexbetrieb möglich. Informationsframes ent¬ 
halten im Control-Feld Zählerwerte, mit denen die Gegenstelle A ihrem Gegenüber B mitteilt, 
welche Nummer der gerade übermittelte Frame besitzt. Des weiteren wird von Station A durch 
eine Framenummer im Control-Feld der Station B übermittelt, bis zu welcher Nummer die 
Station A die von B gesendeten Frames bereits empfangen und verarbeitet hat. Das bedeutet, 
daß mit dem Aussenden eines Informationsframes gleichzeitig eine Bestätigung der bereits 
von der Gegenstelle empfangenen Frames erfolgen kann. 

Das Adreßfeld bei SDLC/HDLC kann benutzt werden, um in Mehrpunktverbindungen, die 
gewünschte Zielstation zu adressieren. Aber auch bei Punkt-zu-Punkt-Verbindungen werden 
Adressen verwendet. Jede Station versendet Informations- und Steuerff ames mit der Zieladresse 
im Adreßfeld. Meldungen/Quittungen werden mit der eigenen (Absende-)Adresse versehen. 


Codierungsverfahren für Datensignale 

Wenn Datensignale nicht mittels MODEM-Verfahren auf Übertragungs wegen übermittelt 
werden sollen, sondern im sogenannten Basisbandverfahren (Basisband deshalb, weil keine 
Umsetzung der Datensignale in einen anderen Frequenzbereich erfolgt!) auf die Leitung 
gelangen, werden unterschiedliche Methoden verwendet, um das Signal z. B. möglichst frei 
von Gleichstromkomponenten (sonst bekommt man die Signale so schlechtdurch Übertrager!) 
zu halten. Einige dieser Verfahren codieren die Daten so um, daß sich möglichst viele 
Zustands wechsel ergeben. Damit läßt sich dann einfacher aus diesem Datenstrom wieder die 
Taktinformation zurückgewinnen! 


Die Umcodierung kann sowohl in Software realisiert als auch (wie beim SCC) durch Hardware 
erledigt werden. 
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NRZ-Verfahren 

Aon Return to Zero. Hier erfolgt eigentlich keine weitere Umcodierung. 

Alle Daten werden durch ihre entsprechenden log. Zustände dargestellt. Um einen möglichst 
geringen Gleichanteil zu haben, wird z. B. die log. 1 durch eine positive Spannung und die 
log. 0 durch eine negative Spannung bezogen auf Masse dargestellt. 

Bei längeren Null- oder Eins-Folgen ist eine Taktrückgewinnung aus dem Datenstrom kaum 
sicher möglich. 


NRZI-Verfahren 

Non Return to Zero - /nverted. Bei jedem Null-Bit wird ein Zustandswechsel durchgeführt! 
Damit ist auch gewährleistet, das bei längeren Null-Folgen Zustandswechsel auftauchen. 
Normalerweise kann auch aus diesem umcodierten Signal nicht besonders effizient die 
Taktinformation zurückgewonnen werden (z. B. bei längeren Eins-Folgen!). 

Da aber bei SDLC/HDLC ja durch die “Zero bit insertion” nach spätestens fünf Eins-Bits eine 
Null eingefügt wird, hat man doch noch eine einigermaßen “wechselhafte” Bitfolge vor sich. 


Biphase Mark-Verfahren oder FMl-Verfahren 

Bei dieser Umcodierung wird an jeder Datenbitgrenze ein Zustandswechsel durchgeführt. Hat 
das darzustellende Datenbit den Wert Eins, so wirdinBitmitteein zusätzlicher Zustandswechsel 
durchgeführt. Dieses Umcodierungsverfahren stellt ausreichend Zustandswechsel zur Takt¬ 
rückgewinnung bereit. 


Biphase Space-Verfahren oder FM0-Verfahren 

Hierbei handelt es sich lediglich um eine Umkehrung des vorgenannten Verfahrens. Also bei 
Null-Bits wird in der Bitmitte ein zusätzlicher Zustandswechsel ausgeführt. 


Manchester-Codierung 

Hierbei wird in Bitmitte immer ein Zustandswechsel durchgeführt. Die Richtung des Zu¬ 
standswechsels gibt dabei den Datenbit-Wert an! 
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Abb. 7.4: Daten-Umcodierungsverfahren 


Der SCC 

Um all die geschilderten Gleichlaufverfahren (Asynchron/Synchronbetrieb), Umcodierungs¬ 
und DÜ-Steuerungsverfahren abwickeln zu können, besitzt der SCC einen komplexen 
Aufbau. 

Zwei voneinander unabhängige Kommunikationskanäle existieren im SCC. Im TT kann dabei 
der SCC-Kanal A zwischen einem 8pol. Miniatur-DIN-Netzwerkanschluß mit elektrischen 
Werten entsprechend RS422 (als LAN bezeichnet) und einem 9pol. SubD-Anschluß (als 
SERIAL 2 bezeichnet) mit elektrischen Werten nach RS232C umgeschaltet werden. 

Die Umschaltung erfolgt durch den IOA7-Port (Pin 14) des Soundchips (Low - LAN / High 
= SERIAL 2). Als Taktquelle für Kanal A des SCC kann sowohl der PCLK mit 8 MHz 
verwendet werden (maximale Datenrate 125 KBit/s) als auch ein 3,672 MHz-Takt von einem 
eigenen Oszillator (maximale Datenrate ca. 230 KBit/s). Außerdem läßt sich bei LAN-Be- 
trieb ein ext. Takt aus dem LAN verwenden. 

Der Kanal B kann im TT/MEGA STE als RS232C-Schnittstelle für unterschiedliche, max. 
Datenraten programmiert werden. Wird der PCLK-Takt von 8 MHz als Ausgangstakt verwen¬ 
det, können bis zu 125 KBit/s erreicht werden. Wenn als Taktquelle der 2,4576 MHz-Takt 
der MFPs benutzt wird, geht die maximale Datenrate bis maximal 153600 Bit/s. Auch der 
Ausgang des Timers C des ST-MFP kann als Taktquelle verwendet werden. Dann reduziert 
sich die maximale Datenrate auf 19200 Bit/s. 
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Abb. 7.5: Block-Diagramm des SCC 


Die zuvor genannten Datenraten gelten für eine Betriebsweise mit einer Art Vorteiler durch 
16, um bei Start/Stop-Betrieb eine stabile Abtastung in Bitmitte erreichen zu können. 

Im Synchronbetrieb, wenn ein zu den Daten passendes Taktsignal vorliegt, lassen sich natür¬ 
lich Geschwindigkeiten erreichen, die dann um den Faktor 16 (Vorteiler nicht erforderlich!) 
höher liegen! 


Ein Blick ins Innenleben des SCC 

Um die verschiedenen Gleichlauf- und DÜ-Steuerungsverfahren unterstützen zu können, ist 
der SCC “ein wenig” komplexer aufgebaut als z. B. ein MFP oder 6850! Auf alle Details des 
SCC hier einzugehen würde den Rahmen des Buches sprengen (allein das kurzgefaßte “Daten¬ 
blatt” zum Z85C30 umfaßt schon mehr als 130 Seiten komprimierte Informationen zu dem 
Baustein!). 
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Der EmpfangsteH des SCC 

Deshalb hier erstmal eine Kurzbeschreibung des Empfängerteils im SCC (jeder Kanal besitzt 
natürlich einen eigenen Empfangsteil!). 



Abb. 7.6: Block-Diagramm des SCC-Empfängers 


Die Daten von der Empfangsdatenleitung gelangen nach einer 1 Bit-Verzögerungsstufe (wird 
im SDLC-Loop-Mode benutzt; dazu später mehr), abhängig von der eingestellten Betriebsart, 
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in die NRZI-Decoderlogik, das S YNC-Empfangsregister oder das Empfangsschieberegister. 
Das SYNC-Empfangsregister hat im SDLC/HDLC-Betrieb zudem die Aufgabe, das vom 
Sender nach jeweils fünf Eins-Bits eingefügte Null-Bit wieder herauszunehmen. 

Sobald ein Zeichen im Empfangsschieberegister “zusammengebaut” ist, gelangt es in ein 3- 
By te-Empfangs-FIFO-Buffer. Damit lassen sich also bis zu drei Bytes Zwischenspeichern, um 
der CPU oder dem DMA-Baustein etwas “Luft” für das Auslesen der Empfangsdaten zu 
lassen. Jedes Auslesen liefert immer das “oberste” Zeichen des FIFO-Buffers und bewirkt 
nach dem Lesezugriff ein Nachrücken der “darunterliegenden” Zeichen! 

Jedes Zeichen, welches in den 3-Byte-FIFO übertragen wird, enthält in einem parallel geführ¬ 
ten 3-Byte-Condition-FIFO-Buffer eine Statusinformation zum Zeichen. Also kann für jedes 
Empfangszeichen die zugehörige Statusinformation aus dem Condition-FIFO-Buffer entnom¬ 
men werden! Dabei sollte beachtet werden, immer erst den Status zum Zeichen auszulesen, 
bevor das eigentliche Zeichen geholt wird. Umgekehrt bekommt man nämlich sonst evtl, den 
Status vom nächsten, bereits “aufgerückten” Zeichen! 

Wenn mit “Special Receive Condition”-Interrupts gearbeitet wird, geschieht eine Interrupt¬ 
anforderung für das “oberste” Zeichen des FIFO-Buffers erst dann, wenn das Zeichen aus¬ 
gelesen wurde! Bei manchen Special-Condition-Interrupt-Betriebs weisen wird zusätzlich der 
gesamte FIFO-Buffer “eingefroren”. So kann dann in “aller Ruhe” die Special Condition aus¬ 
gewertet werden. Erst nach Ausführung eines entsprechenden ERROR-RESET-Kommandos 
wird der FTFO-Buffer wieder “aufgetaut”. Dieses Verhalten erscheint bei DMA-Betrieb recht 
sinnvoll, weil die CPU ja ohne Interrupts nichts vom Datentransfer mitbekommen würde. 

Zusätzlich zum 3-Byte-Condition- und Daten-FIFO-Buffer wird für SDLC/HDLC-Betrieb 
noch ein lOfach-Frame-Status-FIFO-Buffer mit 19 Bit Breite verwendet. Hierin werden, 
ähnlich dem 3 Byte-Condition-PlFO-Buffer für Zeichen, die Statusinformationen der letzten 
zehn Frames aufbewahrt. Ein 14-Bit-Zähler zählt zusätzlich die Datenbytes je Frame (bei 
14 Bit also maximal 16 KByte pro Frame!) und legt diese Zählerstände zusammen mit einer 
5-Bit-Statusinformation in diesem Frame-Status-FIFO-Bufferab. Werden so z. B. Frames per 
DMA-Betrieb im RAM abgelegt, kann anhand der Zählerstände nachträglich jeder einzelne 
Framebeginn im RAM ermittelt und “defekte” Frames ausge”mapped” werden! 

Ebenfalls im Empfangsteil untergebracht ist die CRC-Prüflogik (ein 16-Bit-Schieberegister 
mit entsprechenden Rückkopplungspunkten). Je nach Betriebsart laufen die Daten zur CRC- 
"Berechnung” überdas S YNC-Register (SDLC-CRC) oder das Empfangsschieberegister und 
eine 8-Bit-Puffersmfe (SYNC-CRC) in die Prüflogik ein. 

Das Ergebnis der Blocksicherung wird ebenfalls durch die “Receive-Error-Logic” ausgewer¬ 
tet und als Statusinformation zugänglich gemacht. 
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Im Empfangsteil findet,sich auch die DPLL-Stufe, die aus den Flanken im Empfangsdatensignal 
einen Takt abzuleiten versucht. Dabei kann der Quelltakt für die DPLL-Stufe sowohl vom 
eingebauten Baudraten-Generator (durch einen 16-Bit-Wert Inder Ausgangsfrequenzprogram¬ 
mierbar!) als auch vom RTxC-Eingang gespeist werden (Takt z. B. durch externen Oszillator 
erzeugt). 


Der Sendeteil des SCC 

übernimmt die Umsetzung der parallel eingegebenen Daten in einen seriellen Datenstrom. 
Dazu verfügt der Sender über ein 8-Bit-Sendedatenregister und ein Sendeschieberegister. 
Wenn synchron zeichenorientiert gearbeitet wird (z. B. Bisync- oder Monosync-Verfahren), 
werden die entsprechenden SYNC-Register bei der Bedienung des Sendeschieberegisters 
natürlich mit berücksichtigt. 



Abb. 71: Blockdiagramm des SCC-Senders 
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Immer wenn ein Zeichen aus dem Sendedatenregister ins Sendeschieberegister übergeben 
wurde, wird durch ein entsprechendes Statusbit (oder einen Interrupt) signalisiert, daß das Sen¬ 
dedatenregister nachgeladen werden kann. Auf diese Weise erfolgt im Prinzip die Pufferung 
eines ganzen Zeichens, so daß für die CPU genug Zeit zum “Nachladen” bleibt. 

Je nach Steuerungsverfahren gelangen die Sendedaten noch evtl, über eine Stufe für die “Zero 
Bit Insertion” (bei SDLC/HDLC-Betrieb) und eine Umcodierstufe. Außerdem wird bei Ver¬ 
wendung von Blocksicherungsverfahren nach der CRC-Methode der Datenstrom noch durch 
die CRC-Stufe “geschleust”, um die CRC-Prüfsumme zu “berechnen”. 


Die Register des SCC 

Für die Steuerung des Z85C30 und die Abfrage von Statusinformationen sind eine Menge von 
Registern vorgesehen. Zur Steuerung existieren für jeden Kommunikationskanal 14 Write- 
Register (können nur beschrieben werden). Für Statusinformationen und zum Auslesen der 
Daten existieren je Kanal noch einmal zehn Read-Register! Außerdem haben beide Kanäle 
noch gemeinsam ein Write-Register für den Interrupt-Vektor, den der SCC erzeugen kann, 
und ein Write-Register für die Interrupt-Steuerung. Ähnliches gilt für zwei Read-Register, die 
von beiden Kanälen gemeinsam benutzt werden. 

Im TT (MEGA STE) findet man für jeden der beiden SCC-Kanäle nun nicht jedes Register 
unter einer eigenen Adresse. Vielmehr werden zur Ansteuerung des SCC immer die beiden 
DMA-Bausteine “zwischengeschaltet”. Der DCU übernimmt die Umsetzung des 32-Bit-Da- 
tenbusses auf den 8-Bit-Bus des SCC. Der DMAC ist für die Adressierung und die Erzeugung/ 
Auswertung der Control-Signale zum SCC zuständig. Beide Bausteine “spielen zusammen”, 
wenn der SCC im DMA-Betrieb verwendet wird. 


An welcher Stelle im Adreßraum des TT/MegaSTE findet man nun den SCC bzw. seine 
Register? 

Für jeden SCC-Kanal existieren zwei Adressen, unter denen alle Register des jeweiligen SCC- 
Kanals erreicht werden können. 


Adr. $(FF)FF 8C81 
Adr. $(FF)FF 8C83 
Adr. $(FF)FF 8C85 
Adr. $(FF)FF 8C87 


Control-Reg. SCC 
Data-Reg. SCC 
Control-Reg. SCC 
Data-Reg. SCC 


Kanal A 
Kanal A 
Kanal B 
Kanal A 


Label: “sccctl a” 
Label: “sccdat a” 
Label: “sccctl b” 
Label: “sccdatb” 


Die Data-Register erlauben mit einem Schreibzugriff direktes Einschreiben eines Bytes in den 
Sendebuffer (Write Register 8). Bei einem Lesezugriff erhält man das Byte aus dem Emp- 
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fangsbuffer (Read Register 8). Also ist ein Zugriff auf die “zeitkritischen Daten” ohne große 
Umwege möglich. Die Control-Register werden auf folgende Weise in zwei Stufen “bedient”: 

Der erste Schreibzugriff auf die Control-Register “landet” in Write Register 0 des ent¬ 
sprechenden SCC-Kanals und wird zur Einstellung der gewünschten Registemummer 
verwendet. 

- Der nächste Zugriff (Schreiben oder Lesen) auf das Control-Register erreicht dann das 
im ersten Zugriff ausgewählte Register! 


Write-Register 

Write-Register 0 

(Kommando-Register) 


Mit diesem Register wird festgelegt, welches Register beim nächsten Zugriff auf die gleiche 
Adresse angesprochen werden soll. Außerdem können durch Schreibzugriffe mit entspre¬ 
chenden Bitkombinationen z. B. die CRC-Stufen im Sende- und Empfangsteil zurückgesetzt 
werden, Fehlersignalisierungen und “anhängige” Interrupts gelöscht werden. 


Die nachfolgende Abbildung zeigt die Bitbelegung des Registers, 


Null Code (NOP) — 
Rx CRC-Check Reset — 
Tx CRC-Gener, Reset — 
Tx Underrun Reset — 

Null Code (NOP) — 
POINT HIGH 
Reset Ext./Status Int. — 
Send abort (SDLC/HDLC) 
Enbl.Int.on next Rx Char 
Reset TxINT Pending — 
Error Reset — 

Reset highest IUS-Bit — 


0 0 
0 1 
1 0 
1 1 


4 3 


0 0 0 
0 0 1 


1 0 
1 1 
0 0 
0 1 
1 0 
1 1 


0- 


0 0 0 
0 0 1 
0 1 
0 11 
1 
1 
1 


0 0- 
0 1 ■ 
1 o- 
111 - 


-Reg. 0(8) 
-Reg. 1(9) 
-Reg. 2 (10) 
-Reg. 3 (11) 
-Reg. 4 (12) 
-Reg. 5 (13) 
-Reg. 6 (14) 
-Reg. 7 (15) 


Werte in Klammern gehen dann, wem das POINT HIGH-Kommando in den Bits 5.3 ein¬ 
gestellt ist! 
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Null Code 


Rx-CRC Check Reset 


Tx CRC-Generator Reset 


Tx Underrun Reset/EOM 


Diese Einstellung bewirkt keinerlei Änderung im 
SCC und wird verwendet, wenn bei einem Zugriff auf 
das Write-Register 0 lediglich eingestellt werden 
soll, welches Write-Register beim nächsten Zugriff 
adressiert werden soll. 

Dieses Kommando wird verwendet, um den CRC- 
Prüfer im Empfänger zuriickzusetzen. Der Program¬ 
mierer braucht dies nur dann “von Hand” zu machen, 
wenn im zeichenorientierten Synchronbetrieb (Bisync 
oderMonosync-Betrieb)zwischenempfangenenText- 
blöcken der Empfänger nicht sowieso wieder auf den 
“Hunt mode” (Suchen nach SYNC-Zeichen) einge¬ 
stellt wurde. 

Im SDLC/HDLC-Modus wird der CRC-Prüfer bei 
Erkennen eines Flags automatisch zurückgesetzt, 
ebenso bei “Abschalten” (disablen) des Empfängers. 

Durch dieses Kommando wird im Sender der CRC- 
Generator initialisiert. Das passiert üblicherweise 
während der Initialisierung des SCC oder nachdem 
die CRC-Daten für einen Datenblock ausgesendet 
wurden. 

Latch Reset Mit diesem Kommando wird das Aussenden der 
CRC-Information zum Ende eines Datenblocks (EOM 
= End of Message) gesteuert. 

Wenn durch dieses Kommando das EOM-Flag zu¬ 
rückgesetzt wurde, wird automatisch bei Auftreten 
der Tx Underrun-Bedingung (Keine Daten mehr zum 
Aussenden da, weil anscheinend alles ausgesendet 
wurde!) die CRC-Prüfinformation ausgesendet! Mit 
dem Aussenden der CRC-Information wird dann das 
EOM-Flag gesetzt! 

Dieses Kommando kann jederzeit während des 
Aussendens eines Blocks gegeben werden. Bei aus¬ 
geschaltetem Sender erfolgt durch dieses Kommando 
kein Rücksetzen des EOM-Flags. 
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POINT HIGH Wenn dieses Kommando gesetzt wird, wirkt sich das 

meiner Addition von 8 zum WertderRegistemummer 
in den Bits 0..2 aus. Damit ist dann auch eine Adres¬ 
sierung der Register 8.. 15 möglich. 

Reset External /Status Interrupts Wenn eine Steuerleitung (CTS, DCD) sich geändert 

hat, wird dies in einem entsprechenden Statusbit “ge¬ 
merkt”. Gleiches gilt für spezielle Zustände wie z. B. 
“Break detect” (im Asynchronveifahren wird eine 
Dauer-Null-Bitfolge empfangen). 

Im SDLC/HDLC-Modus ist eine Sendeabbruch-Fol- 
ge mit mehr als sieben Eins-Bits festgestellt worden). 
Durch dieses Kommando lassen sich die Statusbits 
wieder zurücksetzen, und Interrupts, die auf diesen 
Statusbits beruhen, können damit erneut ausgelöst 
werden! 

Send abort (SDLC/HDLC) Durch dieses Kommando wird im SDLC/HDLC-Mo¬ 

dus ein Sendeabbruch signalisiert. Der Sender gibt 
nach Empfang dieses Kommandos zunächst noch den 
Inhalt des Sendepuffers und danach 8.. 13 Eins-Bits 
aus. Anschließend wird das EOM-Flag gesetzt. 

Enable Int. on next Rx Character Empfänger-Interrupts können durch drei voreinstellba¬ 

re Bedingungen ausgelöst werden. Zum ersten kann 
jedesZeichen, welches in den Empfangs-FIFO-Buffer 
gelangt, einen Interrupt auslösen. Zum zweiten läßt 
sich die Interruptsignalisierung für den Empfänger so 
programmieren, daß nur bei speziellen Empfänger- 
Zuständen (z. B. Empfängerüberlauf, Paritätsfehler) 
‘ ‘interrupted” wird. Und zum dritten kann immer dann 
ein Interrupt signalisiert werden, wenn das erste 
Zeichen eines Textblocks (nicht SYNC-Zeichen!) in 
den Empfangs-FIFO-Buffer gelangt. Damit diese 
dritte Intenrupt-Betriebsart jeweils nach Empfang 
eines Textblocks erneut aktiviert werden kann, wird 
dieses Kommando verwendet. 


Reset TxINT pending 


Dieses Kommando wird benutzt, um zu verhindern, 
daß ein weiterer Sender-Interrupt ausgelöst wird, 
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obwohl alle zu sendenden Zeichen ausgegeben wur¬ 
den und der Sendebuffer “leerläuft”. 

Es sorgt dafür, daß erst wieder ein Senderinterrupt 
auftreten kann, wenn das nächste zu sendende Zei¬ 
chen (eines neuen Textblocks!) in das Sendeschiebe¬ 
register übergeben wurde oder wenn eventuelle CRC- 
Bytes komplett ausgesendet wurden. 

Error Reset BeibestimmtenBetriebsartenwerdendieStatusinfor- 

mationen für die Empfangszeichen “eingefroren”. 

Mit diesem Kommando können diese Statusbits zu¬ 
rückgesetzt und der eingefrorene Zustand aufgeho¬ 
ben werden. 

Reset Highest IUS-Bit IUS steht für “Interrupt under Service”. Mit diesem 

Kommando läßt sich gezielt der im Moment am höch¬ 
sten priorisierte Interrupt “abschalten”. Das sollte im¬ 
mer am Ende einer Interrupt-Service-Routine ge¬ 
schehen, um dann den “weniger wichtigen” Interrupts 
auch die Möglichkeit zur Bearbeitung zu geben. 

Die Interrupt-Prioritäten sind beim SCC wie folgt 
gesetzt: 


Empfänger Interrupt Kanal A High 

Sender Interrupt Kanal A 1 

Ext./Status-Int. Kanal A 1 

Empfänger Interrupt Kanal B i 

Sender Interrupt Kanal B !• 

Ext./Status-Int. Kanal B Low 


Write-Register 1 

(Sender/Empfänger Interrupts und Modus-Register für Datentransfer) 

Dies ist das Steuerregister für verschiedene Interrupts des SCC. Außerdem kann hier das 
Handshaking zwischen SCC und DMA-Baustein eingestellt werden. 

Der SCC besitzt für diese Zwecke je Kanal einen programmierbaren Anschluß. 
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Freigabe für Ext,/Status-Interrupts 
Freigabe für Senderinterrupts 
Paritätsfehler als Special Condition ansehen 
Empfängerinterrupts (RxINT) sperren 
RxINT bei erstem Zeichen oder Special Condition 
RxINT bei jedem Zeichen oder Special Condition 
RxINT nur bei Special Condition 
WAIT/DMA-Request beim Senden oder Empfangen 
WAIT oder DMA-Request für Pin _W/_REQ 
Freigabe für WAIT oder DMA-Request 

Freigabe für Ext./Status-Interrupts Dieses Bit ist der “Hauptschalter” für Ext./Status-Inter- 

rupts. Mit Setzen dieses Bits werden alle Interruptquellen, 
deren Freigabe-Bits im Write Register 15 gesetzt sind, 
“scharfgeschaltet”. 

Freigabe für Senderinterrupts Bei gesetztem Bit wird durch den Sender immer dann ein 

Interrupt ausgelöst, wenn der Sendepuffer leer wird. 

Paritätsfehler als Special Condition ansehen 

Bei gesetztem Bit wird ein Paritätsfehler bei einem emp¬ 
fangenen Zeichen als Special Condition angesehen und 
kann einen entsprechenden Interrupt auslösen. 

Empfängerinterrupts (RxINT) sperren 

Wenn der SCC im Polling-Betrieb benutzt wird (die 
CPU schaut immer mal nach, wie der SCC-Status ist. Da¬ 
zu werden z. B. die Statusbits im Read Register 0 be¬ 
nutzt), können durch diese Einstellung die Empfängerin¬ 
terrupts gesperrt werden. 

RxINT bei erstem Zeichen oder Special Condition 

Ein Interrupt wird ausgelöst, sobald ein erstes Zeichen 
im Empfangs-FIFO-Buffer vorliegt oder wenn ein Zei¬ 
chen ausgelesen wird, bei dem eine Special Condition 
aufgetreten ist. Eine Special Condition ist z. B. ein Pari¬ 
tätsfehler (kann separat als Special Condition program¬ 
miert werden!), ein Überlauf des Empfangsregisters, ein 
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CRC-Fehler oder ein Framing Error (= kein Stopbit bei 
Asynchronbetrieb erkannt). DerEmpfangs-FIFO-Buffer 
bleibt so lange “eingefroren”, bis ein Error Reset über das 
Write Register 0 ausgelöst wird. 

RxINT bei jedem Zeichen oder Special Condition 

Jedes empfangene Zeichen löst einen Interrupt aus. 
Außerdem wird ebenfalls ein Interrupt ausgelöst, wenn 
eine Special Condition auftrat. Jedoch wird der Emp- 
fangs-FIFO-Buffer nicht “eingefroren”, bis ein Error 
Reset ausgelöst wird. 

RxINT nur bei Special Condition Bei dieser Einstellung wird nur ein Interrupt ausgelöst, 

wenn beim Zeichenempfang eine Special Condition 
auftrat. Das zugehörige Zeichen bleibt wieder bis zu 
einem Error Reset im Empfangs-FIFO-Buffer “einge¬ 
froren”. 

Für beide SCC-Kanäle gibt es einen Anschluß, der für Betrieb des SCC mit z. B. DMA-Bau¬ 
steinen benutzt werden kann. Im TT ist dieser Anschluß aber nur für den SCC-Kanal A be¬ 
nutzt. Der _W/_REQ-Anschluß kann dabei auf verschiedene Betriebsmodi eingestellt wer¬ 
den. 


- Wait on Transmit. (Bits 7..5 - “100”) 

Bei dieser Einstellung liefert der _W/_RBQ-Pin so lange ein Low, wie der Sendepuffer 
noch gefüllt ist. Sobald der Sendepuffer ein neues Zeichen aufnehmen kann, geht der _W/ 
_REQ-Anschluß in einen hochohmigen Zustand. 

Wait on Receive. (Bits 7..5 = “101”) 

Bei dieser Einstellung liefert der _W/_REQ-Pin ein “Wartesignal” (Low-aktiv), welches 
die CPU bei einem Lesezugriff auf einen leeren Empfangs-FTFO-Buffer zum “Warten” 
auffordert, bis ein Zeichen zum Auslesen vorliegt. Sobald ein Zeichen vorliegt, geht _W/ 
_REQ in den hochohmigen Zustand. 

- DMA-Request on Transmit. (Bits 7..5 = “110”) 

Mit diesem Low-aktiven Signal an _W/_REQ bekommt der DMA-Baustein mitgeteilt, 
wenn der Sendepuffer leer ist und ein neues Zeichen eingeschrieben werden soll. Erst 
wenn ein Zeichen “nachgefüllt” wurde, geht _W/_REQ wieder auf High (wird nicht 
hochohmig!). 

- DMA-Request on Receive. (Bits 7..5 = “111”) 

Auch hier fordert der SCC mit einer fallenden Flanke an _W/_REQ einen DMA-Baustein 
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zur Aktion auf. Nur daß jetzt signalisiert wird, daß ein Zeichen ausdemEmpfangs-FIFO- 
Buffer abgeholt werdenkann. Sollte der SCC in einer Betriebsart für den Empfangsinterrupt 
verwendet werden, die den FIFO-Empfangsbuffer bei Auftreten einer Special Condition 
“einfriert”, so werden natürlich nicht laufend _W/_REQ-Impulse erzeugt (schließlich 
bleibt ja das Zeichen, bei dem diese Special Condition auftrat, im FIFO-Buffer 
eingefroren!). Sobald das Zeichen einmal ausgelesen wurde, geht_W/_REQ wieder auf 
High und reagiert erst wieder “normal”, sobald mit dem Error Reset-Kommando die 
Special Condition beseitigt wurde. 

WAIT/DMA-Request beim Senden oder Empfangen 

Bei gesetztem Bit arbeitet der _W/_REQ-Anschluß für 
den Empfangsteil. Bei gelöschtem Bit wird der _W/ 
_REQ-Anschluß dagegen vom Sendeteil des SCC ge¬ 
steuert. 

WAIT oder DMA-Request für Pin _W/_REQ 

Bit = 0: _ W/_REQ-Pin in WAIT-Betriebsweise. 

Bit = 1: _W/_REQ-Pin in REQUEST-Betriebs- 

weise 

Freigabe für WAIT oder DMA-Request 

Bei gesetztem Bit ist WAIT/REQUEST aktiviert. Bei 
gelöschtem Bit ist weder WAU- noch REQUEST- 
Betriebsart freigegeben. 

Der SCC besitzt je Kanal noch einen weiteren Pin, der als REQUEST-Anschluß für DMA- 
Betrieb verwendet werden kann. Auch dieser Pin ist als Multifunktionsanschluß ausgelegt. Er 
läßt sich sowohl für DMA-REQUEST zur Bedienung des Sendeteils einstellen als auch als 
normaler Schnittstellenanschluß für das DTR-Signal (Data Terminal Ready an MODEM) be¬ 
nutzen. Atari verwendet den DTR/REQ-Pin aber für beide SCC-Kanäle als DTR-Anschluß! 
Deshalb soll hier nicht weiter auf die REQUEST-Betriebsart mit diesem Anschluß eingegan¬ 
gen werden. 

Write-Register 2 

(Interrupt Vektor-Register) 

Der SCC kann, ähnlich dem MFP, während eines Interrupt-Acknowledge-Zyklus eine 
Vektomummer ausgeben. Diese Vektomummer kann hier eingestellt werden. Dabei existiert 
für beide SCC-Kanäle nur ein Interrupt Vektor-Register, daß aber von “beiden Seiten” erreicht 
werden kann. Die Vektomummer kann abhängig von Statusinformationen (wie z. B. 
“Sendepuffer leer”) geändert werden. Dabei läßt sich durch das “Status High/_Status Low“- 
Bit in Write-Register 9 einstellen, welche Bits der Vektomummer durch die Statusinformation 
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beeinflußt werden. Eine Änderung durch Statusinformationen betrifft entweder die Bits 1 „3 
(“Status High/__Status Low”-Bit in Write-Register 9 gelöscht) oder die Bits 4..6 (“Status High/ 
_Status Low”-Bit in Write-Register 9 gesetzt) im Interrupt Vektor-Register. 

Ob überhaupt Statusinformationen die Vektomummer beeinflussen können, wird durch das 
Bit “Vektor includes Status (VIS)” in Write-Register 9 eingestellt (Bit gesetzt: Beeinflussung 
möglich!). 

Welche Beeinflussung die Vektomummer durch die Statusbits erfahren kann, zeigt die 
nachfolgende Tabelle. 


Bit 3 

4 

2 

5 

1 

6 

Status High/ Status Low = 0 

Status High/_Status Low = 1 

Interrupt 

für 

0 

0 

o 

Sendepuffer leer 

Kanal B 

0 

0 

1 

Extemer/Status-Interrupt 

»1 

0 

1 

0 

Empfangszeichen verfügbar 

*> 

0 

1 

1 

Special Condition beim Empfang 

» 

1 

0 

0 

Sendepuffer leer 

Kanal A 

1 

0 

1 

Extemer/Status-Interrupt 


1 

1 

0 

Empfangszeichen verfügbar 

■»> 

1 

1 

1 

Special Condition beim Empfang 

i» 


Im TT/MEGA STE verwendet ATARI eine Vektomummer von $60. Außerdem ist 
standardmäßig das “Status High/_Status Low”-Bit gelöscht, so daß die Intenupt Vektomummer 
durch Statusinformationen in den Bits 3.. 1 beeinflußt wird. Entsprechend findet man im RAM 
des TT/MEGA STE ab der Speicherstelle $180 die zugehörigen Interruptvektoren des SCC 
wieder. Also bei $180 den Zeiger auf die Routine für “Sendepuffer Kanal B leer”, bei $188 
die Adresse der Routine für “Externer/Status-Interrupt Kanal B” usw. 

Write-Register 3 

(Empfängersteuerung) 

Über dieses Register können verschiedene Empfangsparameter eingestellt werden, Hier 
einige Erläuterungen zu den Einstellmöglichkeiten, die nicht unmittelbar ersichtlich sind: 

Address Search Mode Bei gesetztem Bit werden im SDLC/HDLC-Modus nur 

Datenblöcke mit Adressen ausgewertet, die mit der Adresse im 
Write-Register 6 übereinstimmen. Dabei kann allerdings durch 
das Bit 1 im Write-Register 3 (=SYNC-Zeichen nicht in FIFO 
übernehmen) noch bestimmt werden, ob die Empfangsadresse 



Seriell, aber schnell! - Der SCC macht’s möglich 


1155 


exakt mit der Adresse übereinstimmen muß (dann muß Bit 1 
gelöscht sein). Ist im Address Search Mode das Bit 1 gesetzt, 
müssen nur die vier höchstwertigen Bits im Adreßfeld des 
Empfangsblocks mit dem Wert im Write-Register 6 Uberein¬ 
stimmen. 

Suchmodus einschalten Bei gesetztem Bit geht der SCC-Empfangsteil auf “die Suche” 

nach SYNC-Zeichen (im synchronen, zeichenorientierten 
Modus) oder nach Flags (im SDLC/HDLC-Modus). Wenn die 
“Suche” erfolgreich war, wird in Read-Register 0 das Bit 4 
(SYNC/HUNT-BIT) gesetzt und evtl, ein Interrupt ausgelöst. 


0: Empfänger gesperrt/ 1: Empf. eingeschaltet 
Empfangene SYNC-Zeichen nicht in FIFO übernehmen 
Address Search Mode (nur SDLC/HDLC) 
CRC-Priifstufe im Empfänger aktivieren 
Suchmodus einschalten 

Autom. Freigabe f. Rx/Tx durch _DCD und _CTS 

5 Bits/Zeichen 

7 Bits/Zeichen 

6 Bits/Zeichen 

8 Bits/Zeichen 


Write-Register 4 

(Moduseinstellungen für Sender/Empfänger) 

In diesem Register lassen sich neben Sendereinstellungen auch einige Empfängerparameter 

beeinflussen (Registerbelegung siehe folgende Seite). 

Synchronbetrieb einschalten Wenn Synchronbetrieb gewählt ist, werden auch die 

Einstellungen in den Bits 5..4 berücksichtigt. Außerdem 
ist damit automatisch “Takt = 1 x Datenrate” eingestellt 
(die Einstellungen in Bits 7..6 bleiben dann unberück¬ 
sichtigt)! 

MONOSYNC-/BISYNC-Betrieb Wenn MONOSYNC-Betrieb ausgewählt ist, wird die 

Zeichensynchronisierung auf das Zeichen im Write- 
Register 7 eingerastet. 
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Bei BISYNC-Betrieb wird für die Zeichensynchronisie¬ 
rung das Bitmuster aus Write-Register 7 und 6 benutzt. 

SDLC/HDLC-Modus Für den SDLC/HDLC-Modus ist in Write Register 7 das 

Bitmuster für das Flag (7E hex ) einzutragen. Außerdem 
muß für das Blocksicherungsverfahren mittels CRC das 
zu verwendende Prüfpolynom über das Write Register 5 
eingestellt sein. 

Zeichensynchronisation extern Beim SCC kann die Zeichensynchronisation im Syn¬ 
chronmodus auch extern über den _S YNC-Anschluß er¬ 
folgen. Im TT/MEGA STE wird dieser Pin jedoch bei 
beiden SCC-Kanälen für die Abfrage des “Data Set 
Ready”-Signals benutzt. 



0 1 
1 0 
1 1 


Mit Paritätsbit arbeiten 
0: ungerade Parität / 1: gerade Parität 
Synchronbetrieb einschalten 
Asynchronbetrieb mit 1 Stopbit 
Asynchronbetrieb mit 1,5 Stopbits 
Asynchronbetrieb mit 2 Stopbits 
MONOSYNC-Betrieb 
BISYNC-Betrieb 

SDLC/HDLC-Modus (“01111110”-Flag) 

Zeichensynchronisation erfolgt extern 

Takt = 1 x Datenrate 

Takt = 16 x Datenrate 

Takt = 32 x Datenrate 

Takt = 64 x Datenrate 


Write-Register 5 

(Sendersteuerung) 

Bis auf das Bit 2 dieses Registers beeinflussen alle Bits das Verhalten des SCC-Sendeteils. 

Freigabe für Sender-CRC-Generator 

Bei gesetztem Bit durchlaufen die zu sendenden Zeichen den 
CRC-Generator und erzeugen so eine Prüfbitfolge, die am 



Seriell, aber schnell! - Der SCC macht’s möglich 


1157 


7 TeTj 5 _ 432(10 


00 — 

0 1 - 

10 - 

11 — 


Request to Send (RTS) 


Auswahl für CRC-Verfahren 


Freigabe für den Sender 


Ende des Blocks mitgesendet wird. Das Aussenden der CRC- 
Bits erfolgt jedoch erst dann, wenn keine Daten mehr zu senden 
sind. Der SCC erkennt das daran, daß das Senderegister nicht 
mehr “nachgefüllt” wird, also eine Tx Underrun-Bedingung 
entsteht! 


Freigabe für Sender-CRC-Generator 
Request to Send (RTS) 

Auswahl für CRC-Verf. 0: CRC-CCITT/ 1: CRC-16 

Freigabe für den Sender 

BREAK senden (Dauerlage “0” ausgeben) 

5 Bits/Zeichen 

7 Bits/Zeichen 

6 Bits/Zeichen 

8 Bits/Zeichen 

Data Terminal Ready (DTR) 


Dieses Bit steuert den _RTS-Pin des SCC. Bei gesetztem Bit 
geht der „RTS-Anschluß auf Low, bei gelöschtem Bit dann 
entsprechend auf H. . . (na, raten Sie selber mal! Ergebnis 
dann bitte selbst eintragen.) 

Mit diesem Bit läßt sich programmieren, welches Generator¬ 
polynom zur Bildung der Prüfbitfolge benutzt wird. Bei SDLC/ 
HDLC wird das CRC-CCITT -Polynom benutzt (B it=0). Wenn 
synchron, zeichenorientiert gearbeitet wird (z. B. MONOSYNC 
oder BISYNC), kommt meistens das CRC-16-Polynom zur 
Anwendung (Bit=l). Die Einstellungen gelten sowohl für den 
Sender als auch den Empfänger. 

Solange dieses Bit nicht gesetzt ist, werden keine Daten aus¬ 
gesendet. Statt dessen gibt der Sender eine Dauerlage “1” aus. 
Wird nach dem Start einer Übertragung dieses Bit zurückge¬ 
setzt, werden die Daten im Senderegister aber noch komplett 
ausgesendet (gilt auch für SYNC-Zeichen). Wenn allerdings 
während der Übertragung von CRC-Zeichen der Sender abge¬ 
schaltet wird, gelangen statt dessen SYNC-Zeichen oder Flags 
an den Senderausgang. 
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BREAK senden (Dauerlage “0” ausgeben) 

Sobald das Bit gesetzt wird, gibt der Sender nur noch 
Dauerlage “0” aus. Wird das Bit wieder zurückgesetzt, 
geht’s normal mit dem Aussenden der Sendeschiebe¬ 
registerdaten weiter. 

Data Terminal Ready (DTR) Wenn der SCC im DTR-Modus eingestellt ist (über Bit 2 

im Write-Register 14 auswählbar), bestimmt dieses Bit 
den Zustand des _DTR/_REQ-Pins des SCC. Bei ge¬ 
löschtem Bit ist der Anschluß dann High, bei gesetztem 
Bit entsprechend Low. 

Der Inhalt dieses Registers kann auch ausgelesen werden. Dazu ist ein Lesezugriff auf das 
Read-Register 5 durchzuführen, wenn BitO von Write-Register 15 und Bit 6 von Write- 
Regi-ster 7’ gesetzt sind. 

Write-Register 6 

(SYNC-Zeichen / Adresse im SDLC/HDLC-Betrieb) 

Im SDLC/HDLC-Modus enthält dieses Register die Adresse, auf die im “Address Search 
Mode” beim Frame-Empfang “gewartet” wird. Siehe auch bei Write-Register 3! 

Im MONOSYNC-Modus wird in diesem Register das vom Sender verwendete SYNC- 
Zeichen eingestellt. 

Bei BISYNC-Betrieb (Betrieb mit zwei SYNC-Zeichen oder einem 16 Bit-SYNC-Zei-chen, 
je nachdem, wie man die Sache betrachtet) enthält dieses Register die unteren acht Bits des 
SYNC-Zeichens. 

Mit dem Write-Register 7 hat es etwas Besonderes auf sich. Es existiert nämlich im 85C30 
zweimal. Gegenüber seinem “Vorgänger”, dem 8530, hat die im TT/MEGA STE verwendete 
CMOS-Version des Chips einige zusätzliche Möglichkeiten in bezug auf den SDLC/HDLC- 
Betrieb “spendiert” bekommen (wie z. B. der lOfach FRAME-Status-FIFO-Buffer). Um an 
diese zusätzlichen Möglichkeiten und damit auch an das zusätzliche Write-Register 7’ heran¬ 
zukommen, muß SDLC/HDLC-Betrieb eingestellt und das BitO im Write-Register 15 ge¬ 
setzt sein. Aber nun erst einmal zur Funktion des “normalen” Write-Register 7, 

Write-Register 7 

(SYNC-Zeichen 2/ Flag im SDLC/HDLC-Betrieb) 

Im MONOSYNC-Modus wird mit dem Write-Register 7 das Empfangs-SYNC-Zeichen 
festgelegt. 
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Bei BISYNC-Betrieb enthält dieses Register den unteren Teil (oder das zweite SYNC- 
Zeichen, je nach Betrachtungsweise!) des SYNC-Zeichens. 

Im SDLC/HDLC-Modus muß hier das Flag (7E h;s ) eingetragen sein. 

Write-Register 7’ 

(SDLC/HDLC-Optionsregister) 

Nur wenn im SDLC/HDLC-Modus gearbeitet wird, kann auf dieses Register zugegriffen 
werden. 



Auto Freigabe für Senderegister 
Auto EOM-Reset 
Auto RTS-Steuerung 

Dauerlage “1” bei NRZI-Modus und Tx-Disable 
JDTR/_REQ-Timing 
Empfangs-CRC-Bits übergeben 
Erweiterter Lesezugriff auf Write-Register 
Immer “0”! 


Auto Freigabe für Senderegister 

Wenn dieses Bit gesetzt ist, braucht nicht erst das Aussenden 
des Flags abgewartet zu werden, bevor das erste Zeichen in das 
Senderegister gebracht werden kann. Sobald das erste Zeichen 
in das Senderegister gelangt, sendet der SCC das “Eröffnungs”- 
Flag und sendet dann die Daten hinterher. 

Auto EOM-Reset Wenn dieses Bit gesetzt ist, braucht das Rücksetzen des Tx 

Underrun/End Of Message-Flag nicht mehr zu Beginn eines 
Frames “von Hand” durchgeführt zu werden. Der SCC führt 
diesen RESET dann automatisch nach Aussenden des ersten 
Datenbytes durch. 

Auto RTS-Steuerung Bei gesetztem Bit wird das Deaktivieren der RTS-Leitung mit 

dem Aussenden des letzten Bits eines “Schlulf’-Flags synchro¬ 
nisiert. Auch wenn vom Programm schon während des Sendens 
derCRC-Bits bereits RTS abgeschaltet wird, wird der SCC den 
RTS-Anschluß erst deaktivieren, wenn das letzte Bit des 
Schlußflags eines Frames gesendet ist! 
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Dauerlage *T” bei NRZI-Modus und Tx-Disable 

Wenn der Sender abgeschaltet wird, während der SCC in 
NRZI-Kodierung betrieben wird, geht bei gesetztem Bit der 
Ausgangsanschluß auf High. 

_DTR/_REQ-Timing Der _DTR/_REQ-Anschluß des SCC kann auch für DMA- 

Requests programmiert werden. Allerdingsnur für den Sendeteil 
des SCC. Wenn dieses Bit gesetzt ist, verhält sich das Request- 
Timing an diesem Anschluß genauso wie am „W/_REQ-An- 
schluß. Siehe dazu auch Erläuterungen zum Write-Register 1. 

Empfangs-CRC-Bits übergeben 

Bei gesetztem Bit wird die komplette CRC-Prüfbitfolge im 
Empfangsregister zur Verfügung gestellt. Sonst fehlen wegen 
einer 3 Bit-Verzögerungsstufe zwischen SYNC-Register und 
Empfangsschieberegister im Empfangsteil des SCC die letzten 
zwei Bits. 

Erweiterter Lesezugriff auf Write-Register 

Bei gesetztem Bit sind die eigentlich “unleserlichen” Write- 
Register 3..5 und 10 mit einem Lesezugriff enreichbar. 

Allerdings taucht dann Write-Register 3 unter Read-Regi- 
ster 9 auf. Write-Register lOkannausRead-Register II ausge¬ 
lesen werden. Write-Register 4 und 5 erscheinen unter Read- 
Register 4 und 5. 


Write-Register 8 

(Sendedatenregister) 

Dieses Register ist das Sendedatenregister. Im TT/MEGA STE sind sowohl das Write-Re¬ 
gister 8 als auch das Read-Register 8 (Empfangsdatenregister) unter der gleichen (eigenen) 
Adresse zu finden (“sccdat_a” an Adresse $(FF)FF 8C83 und “sccdat_b” an Adresse 
$(FF)FF 8C87). 

Write-Register 9 
(Master Interrupt Control) 

Dieses Register existiert nicht für jeden SCC-Kanal separat, sondern kann von beiden Kanälen 
erreicht werden! 
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VIS (Vector Includes Status) 

NV (No Vector) 

DLC (Disable Lower Chain) 

MIE (Master Interrupt Enable) 

Status High/_Status Low 
Interrupt Acknowledge ignorieren 
Kein RESET 
RESET für SCC-Kanal A 
RESET für SCC-Kanal B 
Hardware RESET durchführen 

VIS (Vector Includes Status) Wie ja bereits beim Write-Register 2 erläutert, kann der Inter¬ 
ruptvektor, den der SCC bei einem Interrupt-Acknowledge- 
Zyklus liefert, abhängig von Statusinformationen, die im Zu¬ 
sammenhang mit dem Interrupt stehen, geändert werden. Bei 
gesetztem Bit liefert der SCC also eine durch Statusinforma¬ 
tionen beeinflußte Vektomummer. 

NV (No Vector) BeigesetztemBitliefertderSCCkeinelnterrupt-Vektomummer 

während eines Interrupt-Acknowledge-Zyklus! 

DLC (Disable Lower Chain) Wenn z. B. mehrere SCCs in einer Interrupt-Verkettung betrie¬ 
ben würden (wie das z. B. mit den beiden MFPs im TT ge¬ 
schieht), könnten durch Setzen dieses Bits die niedriger gewich¬ 
teten Devices von Interruptanforderungen abgekoppelt wer¬ 
den. Im TT/MEGA STE nicht verwendet. 

MIE (Master Interrupt Enable) 

Bei gelöschtem Bit werden keine Interruptanforderungen ge¬ 
stellt. 

Status High/_Status Low Der Zustand dieses Bits legt fest, welche Bits der Interrupt- 

Vektomummer durch Statusinformationen verändert werden 
können. 

Bit - 0: Bits 1..3 der Vektomummer beeinflussen 
Bit = 1: Bits 6..4 der Vektomummer beeinflussen. 

Siehe dazu die Erläuterungen zu Write-Register 2. 
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Interrupt Acknowledge ignorieren 

Bei gesetztem Bit wird ein Interrupt-Acknowledge-Zyklus 
vom SCC ignoriert. 

Kein RESET Dieses Kommando wird nur- benötigt, wenn auf dieses Register 

zugegriffen werden, dabei aber kein Reset ausgelöst werden 
soll. 


Wenn ein RESET für einen der SCC-Kanäle ausgelöst wird, werden Sender und Empfänger 
des entsprechenden Kanals gesperrt. Modem-Steueranschlüsse wie RTS gehen auf High. Alle 
“pending” Interrupts (anstehenden Interrupts) und “Interrupts Under Service” werden zurück¬ 
gesetzt und Interrupts gesperrt. 

Write-Register 10 

(Verschiedene Sender/Empfänger-Kontrollbits) 


In diesem Register sind noch ein paar Bits zur Steuerung des Sende- und Empfangsteils 
untergebracht. 



6 Bit/. 8 Bit SYNC 
Loop Mode 

Send Abort/JFlag bei Underrun setzen 

Mark/_Flag Idle 

Go Active On Poll 

NRZ-Kodierung 

NRZI-Kodierung 

FM 1-Kodierung (Biphase Mark) 

FMO-Kodierung (Biphase Space) 

CRC-mit 1/0 vorbesetzen 

Mit gesetztem Bit kann man bei synchroner, zeichenorientierter 
Betriebsart ein spezielles Format für die SYNC-Zeichen wäh¬ 
len. Diese sind dann im MONOSYNC-Modus nur 6 Bits so¬ 
wohl für Empfänger als auch Sender lang. Im BISYNC-Mo- 
dus werden dann nur 12 Bit-SYNC-Zeichen beim Empfang 
ausgewertet, beim Senden allerdings weiter 16 Bits verwendet. 


Loop Mode 


Im SDLC/HDLC-Betrieb wird eine spezielle Betriebsart für 
Mehrpunktverbindungen verwendet, bei dereine Zentralstation 
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mehrere Unterstationen steuert. Die Unterstationen sind in 
einem Ring hintereinander geschaltet und arbeiten als Repeater 
(Wiederholer). Dabei leitet die Unterstation die von der vorher 
liegenden Station empfangenen Daten zur dahinterliegenden 
Station weiter. Dieses Prinzip wird auch als ‘Token Passing 
Ring” bezeichnet. 

Bei dieser Betriebsart werden vom SCC alle empfangenen Bits 
mit einem 1 Bit-Delay über den Sender wieder ausgegeben. 
Wenn bei einem Poll (= Aufforderung zum Senden) die Unter¬ 
station “merkt” daß sie angesprochen wurde (überdas Adreßfeld 
erkennbar), “klinkt” sie sich mit einem oder mehreren entspre¬ 
chenden “Antwort-Frames” in den Ring ein. 

Durch Setzen des “Loop Mode”-Bits werden Sender und Emp¬ 
fänger zunächst zusammengeschaltet, um den empfangenen 
Datenstrom direkt durchzulassen. Wenn dann das “Go Aktive 
On Poll”-Bit gesetzt wird und mindestens 7 Einsbits (=”End Of 
Poll”-Zeichen = EOP = FE hM oder Ruhezustand mit Dauerlage 
“1” auf der Empfangsleitung) empfangen wurden, geht der 
SCC “On Loop” und schaltet einen 1 Bit-Delay zwischen 
Empfänger- und Senderleitung. 

Bevor eine Unterstation aber selbst senden darf, muß nach dem 
“On Loop”-Schalten ein Flag empfangen werden. Dann hat die 
Station ein weiteres EOP abzuwarten, von dem sie allerdings 
das letzte Einsbit direkt in eine Null umsetzt. Damit entsteht 
daraus für die nächste Unterstation ein Flag! Nun wird der Rest 
des Antwort-Frames der Unterstation ausgesendet, der am 
Schluß wieder mit einem Flag und einem EOP abgeschlossen 
werden muß. Wenn der Antwort-Frame gesendet wurde, ver¬ 
bleibt die Unterstation mit dem 1 Bit-Delay im Ring! 

In synchroner, zeichenorientierter Betriebsart (MONOSYNC 
oder BISYNC) wird dieses Bit gesetzt, um, zusammen mit 
einem gesetzten “Go Aktive On Poll”-Bit, den Sender erst bei 
“eingerasteter” Zeichensynchronisierung freizugeben. 

Send Abort/_Flag bei Underrun setzen 

Nur in SDLC/'HDLC-Betrieb von Bedeutung. Durch dieses Bit 
wird eingestellt, wie der SCC sich bei einem Tx Underrun- 
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Mark/_Flag Idle 


Go Active On Poll 


CRC-mit 1/0 vorbesetzen 


Status verhält (das Senderegister wurde nicht mehr rechtzeitig 
mit Sendedaten “nachgeladen”). Bei gesetztem Bit und Tx 
Underrun-Status sendet der SCC ein Abbruch-Signal (8.. 13 
Einsbits) und ein Flag statt einer CRC-Prüfbitfolge! 

Bei gelöschtem Bit wird dagegen die CRC-Prüfbitfolge gesendet 
und zu Beginn dieses Aussendens das Tx Underrun/EOM-Bit 
in Read Register 0 gesetzt (Kann einen Ext./Status-Interrupt 
auslösen). 

Dieses Bit sollte nach der Ausgabe des ersten Bytes an das 
Senderegister des SCC gesetzt werden. Ein Rücksetzen hat 
dann unmittelbar nach Übergabe des letzten Datenbytes an das 
Senderegister zu erfolgen, um ein einwandfreies Beenden des 
laufenden Frames mit CRC und Flag zu gewährleisten. 

Auch dieses Bit ist nur bei SDLC/HDLC-Betrieb relevant. Bei 
gelöschtem Bit werden im Ruhezustand (Idle State) einer 
Verbindung Flags gesendet. Mit gesetztem Bit gibt der Sender 
Einsbits (in Bytegruppen) als Ruhezustand aus (sinnvoll für die 
Zentralstation in einem Token Passing Ring, zur Erzeugung 
des EOP!). 

Dieses Bit wird beim SDLC-Loop Mode verwendet, um den 
Sender des SCC aufzufordem, sich für einen oder mehrere Ant¬ 
wortframes in den Datenstrom einzuklinken. 

Bei gesetztem Bit “klinkt” sich die Unterstation mit einem Flag 
in den Ring ein. Die zu sendenden Daten müssen dann in das 
Sendedatenregister übergeben werden. 

Bevor die CRC-Prüfbitfolge gesendet wird, muß dieses Bit 
wieder zurückgesetzt sein, sonst werden zusätzliche Flags ge¬ 
sendet. Es ist sinnvoll, dieses Bit nur dann zu setzen, wenn ein 
Poll für die eigene Adresse empfangen wurde. 

Dieses Bit bestimmt den Ausgangszustand des CRC-Schiebe- 
registers im Sender und Empfänger. Bei gesetztem Bit werden 
alle Schieberegisterstufen mit “1” vorbesetzt. Bei gelöschtem 
Bit erfolgt die Voreinstellung entsprechend mit “0”. 
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Write-Register 11 

(Takteinstellung) 



TRxC Out = Quarzoszillator-Ausgang 
TRxC Out = Sendertakt 
TRxC Out = Ausgang des Baudratengenerators 
TRxC Out = Ausgang der DPLL-Stufe 
TRxC-Signalrichtung (0 = Input / 1 = Output) 
Sendetakt kommt vom RTxC-Anschluß 
Sendetakt kommt vom TRxC-Anschluß 
Sendetakt kommt vom Baudratengenerator-Ausgang 
Sendetakt kommt vom DPLL-Ausgang 
Empfangstakt kommt vom RTxC-Anschluß 
Empfangstakt kommt vom TRxC-Anschluß 
Empfangstakt kommt vom Baudratengen.-Ausgang 
Empfangstakt kommt vom DPLL-Ausgang 
RTxC ist Quarzoszillator-Eingang/_TTL-Eingang 


TRxC Out = ... Diese beiden Bits bestimmen, welches Signal am TRxC-Pin 

abgegriffen werden kann (natürlich nur dann von Bedeutung, 
wenn TRxC als Ausgang programmiert ist!). Im TT/ 
MEGA STE wird der TRxC-Anschluß für beide SCC-Kanäle 
als Eingang verwendet! 


RTxC ist Quarzoszillator-Eingang/JTTL-Eingang 

Im TT/MEGA STE wird entweder ein eigener TTL-Takt- 
generator (Kanal A, 3,672 MHz) oder der Takt vom Timer C 
des TT-MFP verwendet (Kanal B). Deshalb ist das Bit ge¬ 
löscht! 


Write-Register 12 +13 

(Low-Byte + High-Byte für Baudratentimer) 

Im SCC ist für jeden Kanal ein eigener Baudratengenerator eingebaut, der mit einem vorein¬ 
stellbaren Abwärtszähler realisiert ist. Der Abwärtszähler ist ein 16 Bit-Zähler, dessen Vor¬ 
einstellung durch die beiden Bytes in den Write-Registem 12 und 13 vorgenommen wird. 

Der Baudratengenerator kann zum einen vom SCC-Mastertakt (8 MHzimTT/MMEGA STE) 
gespeist werden. Die andere Taktquelle im TT/MEGA STE ist der RTxC-Anschluß. 
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Die Ermittlung der Zeitkonstante, die für eine bestimmte Baudrate bei einem vorgegebenen 
Takt gewählt werden muß, geschieht nach folgendem Schema 

Taktfrequenz 

Konstante =-- 2 

2 x Baudrate x Taktmodus 


Taktfrequenz: Eingangsfrequenz des Baudratengenerators 

Taktmodus: Anzahl Taktzyklen je Bit (bei einem Taktmodus von z.B. 16 werden 16 

Taktzyklen für die Ausgabe eines Schritts (Bits) benötigt). 

Das Highbyte der ermittelten Zeitkonstante gehört dann in Write-Register 13. Das Lowbyte 
dementsprechend in Write Register 12. 


Write-Register 14 

(Allgemeine Steuerbits) 


In diesem Write Register finden sich unter anderem Steuerbits für den Baudratengenerator und 
die Digital Phase Locked Loop-Stufe (DPLL). 


E 

6 


0 

0 

2 

TI 

0 


T 


0 0 0 
0 0 1 
0 10 
0 11 
10 0 
10 1 
110 
111 


Baudratengenerator freigeben 
Taktquelle für Baudratengenerator 
JDTR/_REQ-Auswahl 
Auto Echo 

Lokale Schleife Sender -> Empfänger 
Null Command 
Flanke suchen 
Taktfehler-Flags rücksetzen 
DPLL abschalten 

DPLL-Taktquelle = Baudratengenerator-Ausgang 
DPLL-Taktquelle = RTxC-Anschluß 
Taktrückgewinnung aus FM-codierten Daten 
Taktrückgewinnung aus NRZI-codierten Daten 


Taktquelle für Baudratengenerator 

Bei gesetztem Bit wird der PCLK des SCC als Mastertakt für 
den Baudratengenerator verwendet. Bei dem im TT/ 





Seriell, aber schnell! - Der SCC macht’s möglich 


1167 


_DTR/_REQ-Auswahl 


Auto Echo 


Lokale Schleife Sender 


Flanke suchen 


MEGA STE benutzten Takt von 8 MHz sind damit bei einem 
Taktmodus von 16 Baudraten im Asynchronmodus bis zu 
125000 Bit/s erreichbar. 

Wenn das Bit gelöscht ist, kommt der Takt vom RTxC-An- 
schluß. Im TT/MEGA STE liegt für den Kanal A an RTxCA 
ein 3,762 MHz-Takt an. Der Kanal B wird an RTxCB vom Ti¬ 
mer C-Ausgang des TT-MFP gespeist. 

Mit diesem Bit wird eingestellt, ob der JDTR/_REQ-Anschluß 
des SCC als Data Terminal Ready-Ausgang (Bit = 0) oder als 
Request-Ausgang für DMA-Betrieb verwendet wird (Bit =1). 
Im TT/MEGA STE wird die DTR-Funktion benutzt! 

Bei gesetztem Bit wird intern der Senderausgang auf den Emp¬ 
fängereingang geschaltet. Der Empfänger reagiert aber weiter¬ 
hin auf Empfangsdaten von “außen”. CTS als Senderfreigabe 
wird ignoriert. 

-> Empfänger 

Bei gesetztem Bit werden die Sendedaten sowohl am Aus¬ 
gangsanschluß ausgegeben als auch auf den Empfänger zu¬ 
rückgeführt. CTS und DCD werden ignoriert. 

Die DPLL-Stufe schaltet bei gesetztem Bit in einen Suchmodus, 
mit dem sie eine Flanke zum “Einrasten” im ankommenden 
Datenstrom sucht. 

Zur einwandfreien Betriebsweise der DPLL muß bei NRZI- 
kodierten Datenströmen ein Quellentakt verwendet werden, 
der das 32fache der Datenrate beträgt. Nachdem eine Datenflan¬ 
ke erkannt wurde, schaltet die DPLL auf Normalbetrieb um 
und justiert sich an weiteren Flanken jeweils nach. 

Bei FM-kodierten Datenströmen wird die DPLL-Stufe mit 
Quelltakten “gefahren”, die das löfache der Datenrate aufwei¬ 
sen. Wenn weitere Flanken nicht im erwarteten Taktraster 
gefunden werden, setzt die DPLL entsprechende Statusbits 
(“One Clock Missing”- und “Two Clock Missing”-Bit in Read 
Register 10). Wird zweimal die Datenflanke an der erwarteten 
Position nicht mehr erkannt, wechselt die DPLL-Stufe automa¬ 
tisch wieder in den “Flanke suchen”-Modus. 



1168 


ATARI Profibuch 


Taktfehler-Flags rücksetzen Mit diesem Kommando werden die zuvor erwähnten “One 

Clock Missing”- und “Two Clock Missing”-Bits zurückge¬ 
setzt. 

DPLL abschalten Die DPLL-Stufe wird abgeschaltet, die “Clock Missing”-Bits 

zurückgesetzt und ein Dauer-"Flanke suchen "-Modus einge¬ 
schaltet. 

Write-Register 15 

(Ext./Status-Interrupt-Steuerung) 

Wenn Ext./Status-Interrupts durch Write-Register 1 eingeschaltet sind, wird in diesem Write- 

Register festgelegt, welche Zustände einen Interrupt auslösen können. 


Zugriff auf Write-Register 7’ ermöglichen 
Freigabe für “Zero counf'-Interrupt 
lOfach Frame-Status-FIFO benutzen 
Freigabe “Data Carrier Detecf-Interrupt (DCD) 

Freigabe für SYNC/Suchmodus-Interrupt 
Freigabe für “Clear To Send”-Interrupt (CTS) 

Freigabe für Tx Underrun/EOM-Interrupt 
Freigabe für Break/Abort-Interrupt 

Zugriff auf Write Register 7’ ermöglichen 

Bei gesetztem Bit kann im SDLC/HDLC-Modus auf das Write 
Register 7’ mit seinen zusätzlichen Möglichkeiten zugegrif¬ 
fen werden. 

Freigabe für “Zero counf'-Interrupt 

Bei gesetztem Bit wird ein Interrupt ausgelöst, wenn der Zähler 
im Baudratengenerator den Wert 0 erreicht. 

lOfach Frame-Status-FIFO benutzen 

Bei gesetztem Bit ist im SDLC/HDLC-Modus der lOfach 
Frame-Status-FIFO eingeschaltet. 

Freigabe “Data Carrier Detecf'-Interrupt (DCD) 

Bei gesetztem Bit führt eine Zustandsänderung am DCD- 
Anschiuß zu einem Interrupt. 
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Freigabe für SYNC/Suchmodus-Interrupt 

Bei gesetztem Bit wird im Asynchronmodus bei einer Zu¬ 
standsänderung am SYNC-Anschluß des SCC ein Interrupt 
ausgelöst. 

Im TT/MEGA STE wird der SYNC-Anschluß bei beiden 
SCC-Kanälen für die Abfrage der “Data Set Ready (DSR)”- 
Leitung benutzt. 

Im Synchron-Modus erfolgt eine Interruptauslösung, wenn ein 
SYNC-Zeichen oder Flag im Empfangsdatenstrom erkannt 
wurde. 

Freigabe für “Clear To Send”-Interrupt (CTS) 

Bei gesetztem Bi t wird ein Interrupt durch Zustandsänderungen 
am CTS-Anschluß ausgelöst. 

Freigabe für Tx Underrun/EOM-Interrupt 

Wenn im Sender das Tx Undermn/EOM-Flag gesetzt wird, löst 
das einen Interrupt aus. 

Freigabe für Break/Abort-Interrupt 

Bei gesetztem Bit werden Interrupts ausgelöst, wenn vom 
Empfänger ein Break (Dauerlage “0”) im Asynchronmodus 
oder ein Abort (mindestens sieben Einsbits) im SDLC/HDLC- 
Modus erkannt wurde. 

Soviel zu den Write-Registem des SCC. 


Read-Register 

Nun kommen die Read Register an die Reihe, die dem Programmierer eine Menge an Statusin¬ 
formationen und natürlich auch die empfangenen Daten liefern. 

Read-Register 0 

(Status der Sende- und Empfangsbuffer) 

In diesem Register finden sich Flags für die wohl wichtigsten Zustände des Sende- und 
Empfangsteils des SCC wieder. Unter anderem findet man hier auch die Flags wieder, die als 
Quellen für Ext./Status-Interrupts fungieren. 
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Q 

6 

0 

0 

0 

0 

0 

0 


Min. 1 Empfangszeichen kann ausgelesen werden 
Zähler im Baudratengen, hat Null erreicht 
Senderegister muß “nachgeladen” werden 
Zustand des DCD-Anschlusses (0 = High /1 = Low) 
Zustand des SYNC-Pins/SYNC-Zeichen erkannt 
Zustand des CTS-Anschlusses (0 = High / 1 = Low) 
Tx Underrun/EOM ist aufgetreten 
Break empfangen/Abort-Sequenz empfangen 


Hier noch einige zusätzliche Erläuterungen zu bestimmten Flags: 

Zähler im Baudratengen, hat Null erreicht 

Wenn im Write Register 15 der "Zero Count”-Interrupt freige¬ 
geben ist, wird dieses Bit so lange auf “1” gesetzt, wie im 
Abwärtszähler des Baudratengenerators der Zählerstand Null 
existiert! Solange bleibtauch eine “Zero Counf’-Interruptanfor- 
derung “stehen”. Wenn allerdings zu diesem Zeitpunkt bereits 
ein anderer Ext./Status-Interrupt “anhängig” (pending) ist, 
wird ein “Zero Count”-Interrupt nur dann ausgelöst, wenn die 
Interruptbedingung (Abwärtszähler ist auf Null) auch nach Be¬ 
endigung der gerade laufenden Interrupt-Service-Routine noch 
besteht! 


Zustand des DCD-Anschlusses 

Wenn der DCD-Interrupt (Bit 3 im Write Register 15) nicht 
freigegeben ist, kann über dieses Bi t der Zustand der DCD-Lei- 
tung abgefragt werden (0 = High / 1 = Low). 

Ist der DCD-Interrupt freigegeben, wird bei einem Ext./Status- 
Interrupt der Zustand des DCD-Anschlusses zum Interruptzeit¬ 
punkt “eingefroren” und kann durch die Interrupt-Service- 
Routine abgefragt werden. Wenn gerade kein anderer Ext./ 
Status-Interrupt “pending” ist, löst ein Zustandswechsel am 
DCD-Anschluß natürlich einen entsprechenden Interrupt aus. 

Zustand des SYNC-Pins/SYNC-Zeichen erkannt 

Bei Synchronbetrieb wird dieses Bit durch das Kommando 
“Suchmodus einschalten” in Write Register 0 gesetzt. Sobald 
der Empfänger dann Zeichensynchronismus erreicht (durch 
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SYNC-Zeichen oder Flags im SDLC/HDLC-Modus), wird 
dieses Bit wieder zurückgesetzt. Wenn im Write Register 15 
“Freigabe für SYNC/Suchmodus-Interupts” eingestellt ist, 
wird bei jeder Änderung dieses Flags ein Ext./Status-Interrupt 
ausgelöst. 

Im Asynchronbetrieb signalisiert dieses Bit den Zustand des 
SYNC-Anschlusses des jeweiligen SCC-Kanals (1 = Low / 0 
= High am S YNC-Pin). Im TT/MEGA STE läßt sich über den 
SYNC-Anschluß so die “Data Set Ready (DSR)”-Leitung 
eines MODEM aus werten. 


Zustand des CTS-Anschlusses 

Dieses Bit reagiert für den CTS-Anschluß des SCC-Kanals 
genauso, wie sich Bit 3 für den DCD-Anschluß verhält. 

Tx Underrun/EOM ist aufgetreten 

Dieses Bit ist nach einem RESET, bei abgeschaltetem Sender 
und nach einem “Send abort”-Kommando gesetzt. Ein Rück¬ 
setzen ist nur durch das “RESET Tx Underrun/EOM-Bit”- 
Kommando in Write Register 0 möglich. Sobald dann eine Tx 
Underrun-Bedingung auftritt, wird dieses Bit wieder gesetzt 
und ein Ext./Status-Interrupt ausgelöst (wenn dieser über das 
Bit 6 im Write-Register 15 eingeschaltet wurde!). 

Break empfangen/Abort-Sequenz empfangen 

Im Asynchron-ßetrieb wird dieses Bit gesetzt, wenn ein Break 
im einlaufenden Datenstrom “gesichtet” wurde (ein Zeichen, 
bei dem alle Bits Null sind und kein Stopbif erkannt wurde = 
Framing Error). Dieses Break erzeugt im Empfangs-FEFO- 
Buffer ein einzelnes “Nullzeichen”, welches ausgelesen und 
verworfen werden sollte. Mit Übergabe des “Nullzeichens” in 
den Empfangs-FIFO-Buffer wird dieses Bit allerdings schon 
wieder zurückgesetzt! Wenn das zugehörige Enable-Bit im 
Write Register 15 gesetzt ist, wird natürlich ein Ext./Status- 
Interrupt ausgelöst. 

Im SDLCIHDLC-Betrieb wird dieses Bit gesetzt, wenn eine 
Abort-Sequenz (sieben oder mehr Einsbits) erkannt wurde. 
Wenn die Abort-Sequenz beendet wird, wird dieses Bit wieder 
zurückgesetzt. Auf jeden Fall wird bei eingeschalteter “Break/ 
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Abort”-Freigabe Bit in Write Register 15 ein Ext./Status- 
Interrupt ausgelöst, egal ob bereits ein solcher Interrupt “an¬ 
hängig” ist oder nicht!! 


Read-Register 1 

(Special Receive Condition-Bits) 

Aus diesem Register können unter anderem die Statusinformationen zu dem parallel im 
Empfangs-FIFO-Buffer liegenden Empfangszeichen ausgelesen werden. 



All sent 

Residuen Code 2 

Residuen Code 1 

Residuen Code 0 

Paritätsfehler 

Rx Overrun 

CRC/Framing Error 

End of Frame (SDLC/HDLC) 


All sent Im Asynchronbetrieb wird dieses Bit gesetzt, wenn alle 

Sendedatenbits das Sendeschieberegister verlassen haben. 

Residuen Code 2, 1 und 0 Diese Bits sind nur im SDLC/HDLC-Betrieb interessant und 

. das auch nur dann, wenn das End of Frame-Bit ebenfalls gesetzt 
ist. 

Wenn nämlich das Datenfeld eines Frames kein ganzzahliges 
Vielfaches der eingestellten Zeichenlänge (üblicherweise 
acht Bits) ist, werden diese Residuen Bits herangezogen, um 
zu ermitteln, wo die Grenze zwischen den letzten Bits des Da¬ 
tenfelds eines Frames und der CRC-Prüfbitfolge liegt! Emp¬ 
fangene Datenbits in einem Zeichen werden immer rechts ju¬ 
stiert! 

Die folgende Tabelle zeigt die Zusammenhänge zwischen den 
Residuen Bits und der Lage der Datenbits in den letzten gelese¬ 
nen Zeichens eines Frames für unterschiedliche Zeichenlängen. 
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Res. 

Bits 

im letzten Byte ' 

Bits 

im vorletzten 

Byte 

Bits 

im drittletzten Byte 

Bits 

8B 

7B 

6B 

5B 

8B 

7B 

6B 

5B 

8B 

7B 

6B 

5B 

0 1 2 

/z 

/z 

/Z 

TL 

TL 

TL 

TL 

TL 

TL 

TL 

TL 

TL 

100 

0 

0 

0 

0 

3 

1 

0 

0 

8 

7 

5 

2 

0 1 0 

0 

0 

0 

0 

4 

2 

0 

0 

8 

7 

6 

3 

1 10 

0 

0 

0 

0 

5 

3 

1 

0 

8 

7 

6 

4 

00 1 

0 

0 

0 

0 

6 

4 

2 

0 

8 

7 

6 

5 

101 

0 

0 

0 

0 

7 

5 

3 

1 

8 

7 

6 

5 

0 1 1 

0 

0 

0 

- 

8 

6 

4 

- 

8 

7 

6 

- 

111 

1 

0 

- 

- 

8 

7 

- 

- 

8 

7 

- 

- 

000 

2 

- 

- 

- 

8 

- 

- 

- 

8 

- 

- 

- 


Paritätsfehler 


Rx Overrun 


Wenn die Paritätsprüfung eingeschaltet ist, wird dieses Bit bei 
jenen Zeichen gesetzt, die ein nicht übereinstimmendes 
Paritätsbit aufweisen. Wenn ein Paritätsfehler auftrat, bleibt 
dieses Bit auch bei allen folgenden Empfangszeichen gesetzt 
(und es werden evtl, so lange Special Condition-Interrupts aus¬ 
gelöst), bis mit dem Error Reset-Kommando dieser Zustand 
gelöscht wird! 

Ein gesetztes Bit zeigt einen Überlauf des Empfangs-FIFO- 
Buffers an. Aber nur das Zeichen, für den dieser Überlauf sig¬ 
nalisiert wurde ist “überrannt” worden. Allerdings bleibt die 
Fehlerbedingung für alle weiteren Empfangszeichen gesetzt, 
bis ein Error Reset ausgeführt wird. 


CRC/Framing Error Im Asynchronbetrieb wird durch ein gesetztes Bit ein Framing 

Error signalisiert. Damit wird angezeigt, daß zu einem Emp¬ 
fangszeichen kein Stopschritt (Bit) empfangen wurde. Dieser 
Rahmenfehler wird nur für das Zeichen signalisiert, bei dem 
dieser Fehler auftrat (also nicht bis zu einem Error Reset-Kom¬ 
mando ge”Iatched”). 


Im Synchronbetrieb wird dieses Bit gesetzt, wenn beim Ver¬ 
gleich der augenblicklichen Prüfbitfolge in der CRC-Stufe mit 
dem festgelegten OK-Prüfmuster keine Übereinstimmung fest- 
gestellt wurde. Das dürfte meistens der Fall sein, außer wenn 
der Datenblock komplett fehlerfrei empfangen wurde. Das Bit 
wird auch hier nicht gelatched und kann jederzeit mit einem 
Error Reset-Kommando gelöscht werden. Mit jedem neuen 
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empfangenen Zeichen wird dieses Bit erneut dem Vergleich 
entsprechend gesetzt. Um eine korrekte Statusaussage über die 
CRC-Priifung zu erhalten, sollte dieses Bit nur in Verbindung 
mit dem “End of Frame”-Bit ausgewertet werden. 

End of Frame Im SDLC/HDLC-Modus wird durch ein gesetztes Bit ange¬ 

zeigt, wenn ein gültiges “Closing”-Flag empfangen wurde. 
Damit sind dann auch das CRC/Framing Error-Bit und die 
Residuen Code-Bits gültig. Mit dem ersten empfangenen 
Zeichen des nächsten Frames wird der Zustand dieses Bits 
wieder aktualisiert (also zurückgesetzt!). Ein Rücksetzen ist 
ebenfalls mit dem Error Reset-Kommando möglich. 

Read-Register 2 
(Interrupt-Vektor) 

Aus diesem Register kann der Interrupt-Vektor ausgelesen werden, der über das Write 
Register 2 in den SCC eingeschrieben wurde. Dabei gibt es jedoch eine Besonderheit zu 
beachten: 

- Wenn dieses Register im Kanal B ausgelesen wird, erhält man den aktuellen, evtl, durch 
Statusinformationen veränderten Interrupt-Vektor. 

- Erfolgt das Auslesen aus dem Kanal A, erhält man lediglich den aktuell dort gespeicher¬ 
ten Interrupt-Vektor ohne Statusbeeinflussung. 

Read-Register 3 

(Interrupt Pending Register) 

Hier werden alle “anhängigen” Interrupts durch ein gesetztes Bit signalisiert. Allerdings kann 
dieses Register nur vom Kanal A ausgelesen werden! Im Kanal B erscheinen alle Bits als 
Nullbits. 



Ext./Status-Interrupt 

Kanal B 

Senderinterrrupt 

t« 

Empfangsinterrupt 

u 

Ext./Status-Interrupt 

Kanal A 

Senderinterrrupt 


Empfangsinterrupt 

0 

0 

u 
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Read-Register 6 

(LSB des 14 Bit-Zählerstands aus Frame-Status-FIFO-Buffer) 

Wenn der SCC im SDLC/HDLC-Betrieb arbeitet und Bit 2 im Write Register 15 gesetzt ist, 
können hier die untersten 8 Bits des an oberster Position des Frame-Status-FIFO-Buffers 
stehenden Frame-Byte-Zählerstandes ausgelesen werden.Dierestlichen sechs Zählerstandsbits 
kommen aus Read Register 7. 

Read-Register 7 

(MSB des 14 Bit-Zählerstands aus Frame-Status-FIFO-Buffer) 

Auch dieses Register ist nur “zugänglich”, wenn im Write Register 15 das Bit 2 gesetzt ist. 
Die unteren sechs Bits dieses Registers enthalten die höchstwertigen Zählerstandsbits aus dem 
lOfach Frame-Status-FIFO-Buffer. 

Ein gesetztes Bit 7 dieses Registers signalisiert einen Überlauf des lOfach Frame-Status- 
FIFO-Buffers. 

Wenn Bit 6 gesetzt ist, kommt die Statusinformation für den Frame aus dem FIFO-Buffer, Bei 
Bit 6=0 kommt die Statusinformation nicht aus dem Zwischenbuffer (der ist dann noch leer), 
sondern direkt aus dem Empfänger (Read Register 1)! 


Read-Register 10 

(Loop/Clock Status) 


LL 

6 

5 

fT 

[31 

2 




| - 0 

On Loop 

l-o 

I---— o 

- On Loop and Sending 

-0 

-— Two Clocks Missing 

——---- One Clock Missing 

On Loop Dieses Bit ist gesetzt, wenn sich der SCC im SDLC-Loop- 

Modus befindet. 


On Loop and Sending 


Dieses Bit wird im SDLC-Loop-Modus dann gesetzt, wenn der 
Sender selbst Daten auf den Ring ausgibt. 
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Two Clocks Missing Wenn die DPLL-Stufe im FM-Modus betrieben wird und diese 

bei zwei Versuchen keine Datenflanke erkannt hat, wird dieses 
Bit gesetzt. Gleichzeitig schaltet die DPLL in den Suchmodus! 
DasBitbleibtdann gesetzt, bis ein “Taktfehler Flags rücksetzen”- 
oder ein “Flanke suchen”-Kommando über Write-Register 14 
gegeben wird. 

One Clock Missing WenndieDPLL-StufeimFM-Modusbetriebenwirdunddiese 

keine Datenflanke an der Stelle erkannt hat, wo eigentlich eine 
sein müßte, wird dieses Bit gesetzt. Das Bit bleibt dann gesetzt, 
bis ein “Taktfehler Flags rücksetzen”- oder ein “Flanke su- 
chen”-Kommando über Write-Register 14 gegeben wird. 


Read-Register 12 und 13 

(Low- und High-Byte der Baudratengen.-Zeitkonstanten) 

Aus diesenbeidenRegistemkanndieüber Write-Register 12 und 13 eingestellte Zeitkonstante 
für den Abwärtszähler des Baudratengenerators ausgelesen werden. 

Read-Register 15 

(Ext./Status-Interrupt-Freigabe-Bits) 

Die über das Write-Register 15 eingestellten Freigabe-Bits für Ext./Status-hnterrupts können 
hierüber wieder ausgelesen werden. Die Beschreibung der einzelnen Bits kann bei Write- 
Register 15 nachgeschlagen werden. 


E 

6 

0 

3 

3 

0 

i 

3 


1 r 

i 


t 

T 


1 - Zugriff auf Write Register 7’ 

- Freigabe für “Zero counf’-Interrupt 

- lOfach Frame-Status-FEFO benutzbar 

-Freigabe “Data Carrier Detect”-Interrupt (DCD) 

-Freigabe für SYNC/Suchmodus-Interrupt 

1 — -Freigabe für “Clear To Send”-Interrupt (CTS) 

-Freigabe für Tx Undemm/EOM-Interrupt 

. .. Freigabe für Break/Abort-Interrupt 

Die Programmierung des SCC 


Die Programmierung des SCC mit seinen vielfältigen Möglichkeiten muß natürlich entspre¬ 
chend sorgfältig vorgenommen werden. Aus diesem Grunde hat der Hersteller des SCC ein 
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bestimmtes Schema vorgeschlagen, um die Initialisierung des SCC vorzunehmen. Die 
Einstellung des SCC erfolgt dabei in einer vorgegebenen Reihenfolge in drei Abschnitten. 

1. Einstellung der Betriebsmodi wie Bits/Zeichen, Parität. Außerdem gehört dazu das Vor¬ 
besetzen der einzelnen Register mit Konstanten (z. B. Interrupt-Vektor, Zeitkonstante 
für Baudratengenerator). 

2. Im nächsten Schritt erfolgt die Freigabe der einzelnen Hardware-Funktionen. Dazu ge¬ 
hört unter anderem die Freigabe für Sender und Empfänger sowie Baudratengenerator 
und DPLL. Wichtig ist dabei, daß die Betriebsmodi vorher eingestellt wurden. 

3. Der dritte Abschnitt ist optional und nur von Belang, wenn mit Interrupts gearbeitet wird. 
Dazu gehört dann die Freigabe der benutzten Interrupts. 

Nachfolgend deshalb das Schema für die Initialisierung des SCC. Diese Prozedur ist natürlich 
für jeden Kommunikationskanal durchzuführen. 

Dabei sind jene Register besonders gekennzeichnet, deren Programmierung nicht zwingend 
erforderlich ist. Alle mit einem “X” markierten Bitpositionen sind dabei vom Programmierer 
einzustellen. Ein “S”-Bit bedeutet, daß dieses Bit in seinem bereits zuvor eingestellten Zu¬ 
stand zu belassen ist. 


Betriebsmodi und Konstanten einstellen 


Write 

Reg.# Bitbelegung 


9 

T 

i 

0^ 

0 

0 

0 

0_ 

ol 

4 

m 

K3 

□ 

E3 

0 

X 

0 

El 

1 

El 

m 

X 

O 

El 

ES 

Ul 

0 

2 

0 


X 

X 

X 

X 

X 

X 

3 

E 

m 

ES 

B 

0 

X 

X 

0 

5 

E 

B 

ES 

B 

El 

X 

X 

0 

6 

E 

Kl 

B 

X 

m 

B 

0 

0 

7 

E 


ES 

X 

0 

X_ 

X 

X 

9 

0 

Bl 

19 

X 

0 

ES 

0 

X 


X 

X 

L x 

ES 

0 

ES 

Q 

B 

11 

E 

B 

B 

B 

0 

ES 

i 

0 

12 


m 

Ei 

x~ 

0 

■3 

m 

0 

13 



B 

X 

0 

B 

m 

0 

14 

E 


El 

X 

0 

ES 

0 

0 

14 

D 

B 

El 


0 

m 

m 

0 


Aktion Anm. 


Hardware Reset ausführen 
Tx/Rx-Cont. Async/Sync-Modus 
W/_REQ f. DMA-Betrieb einst, opt. 
Int.-Vektor programmieren opt. 
Empf.-Parameter einstellen 
Sender-Parameter einstellen 
SYNC-Zeichen programmieren opt. 
SYNC-Zeichen programmieren opt. 
Master-Int. Steuerung 
Div. Tx/Rx-Einstellungen opt. 
T akteinstellungen 

BRG-Zeitkonstante Low-Byte opt. 
BRG-Zeitkonstante High-Byte opt. 
Allg. Steuerbits einstellen 
Verschiedene Kommandos opt. 
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Freigabe der Hardware-Funktionen 
Write 

Reg.# Bitbelegung 


14 

3 

5 

0 

1 


TI 

0 

0 

s 

s 

s 

s 

1 

s 

s 

s 

s 

s 

s 

s 

1 

s 

s 

s 

s 

1 

s 

s 

s 

l 

0 

0 

0 

0 

0 

0 

0 

x 

's 

s 

0 

0 

s 

0 

0 


Aktion 


Anm. 


Baudratengen. freigeben 
Empfänger freigeben 
Sender freigeben 

Tx CRC-Gener. zurücksetzen opt. 

DMA-Betrieb freigeben opt. 


Freigabe der Interrupts 
Write 

Reg.# Bitbelegung Aktion Anm. 


15 

0 

0 

1 

9 


X 

X 

X 

X 

X 

X 

X 

X 

0 

0 

0 

1 

0 

0 

0 

0 

0 

0 

0 

1 

_Qj 

0 

0 

0 

s 

s 

s 

X 

TI 

s 

X 

X 

0 

0 

0 

s 

X 

s 

s 

s 


Ext./Status-Int. selektieren 
Reset Ext./Status-Int. 

Reset Ext./Status-Int. (nochmal!) 
RxyTx + Ext./Status-Int. aktivieren 
“Hauptschalter” für Int. auf “Ein” 


Vor der Initialisierung des SCC sollte auf jeden Fall ein Reset ausgeführt werden. Wenn bereits 
ein Kanal initialisiert ist, braucht natürlich für die Initialisierung des zweiten Kanals kein 
erneuter Hardware-Reset durchgeführt zu werden. Dazu “reicht” dann ein Kanal-Reset für den 
zweiten Kanal! 


Betrieb des SCC im TT 

Auch dem SCC hat ATARI für den schnellen Datenaustausch eine eigene DMA-Einheit zur 
Seite gestellt. Verwendet wird ein zweiter Satz mit den gleichen DMA-Chips, wie bereits beim 
SCSI-Port des TT beschrieben. Allerdings gilt die DMA-Unterstützung nur für den Kanal A 
des SCC! 

SCC-DMA-Betrieb ist auch hier auf jede RAM-Adresse möglich. Weil die grundsätzlichen 
Angaben zu den DMA-Bausteinen ja bereits bei der Beschreibung des SCSI-Ports gemacht 
wurden, soll hier nur auf die Lage der SCC-DMA-Register im Adreßraum eingegangen wer¬ 
den. 
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Die SCC-DMA-Register 

Die Registeradressen des SCC-DMA-Chips liegen sowohl amoberenEnde des ST-Adreßraums 
($FF 8CXX) als auch ganz oben im TT-Adreßraum ($FFFF 8CXX). Angegeben ist hier je¬ 
weils die Lage im ST-Adreßraum! 


Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 8C01 

R/W 

DMA-Address-Pointer (Highest Byte) 

“scdmabas” 

$FF 8C03 

R/W 

DMA-Address-Pointer (High Byte) 

“scdmabas”+2 

$FF 8C05 

RAV 

DMA-Address-Pointer (Low Byte) 

“scdmabas”+4 

$FF 8C07 

RAV 

DMA-Address-Pointer (Lowest Byte) 

“scdmabas”+6 

$FF 8C09 

RAV 

DMA-Bytezähler (Highest Byte) 

“scdmacnt” 

$FF 8C0B 

RAV 

DMA-Bytezähler (High Byte) 

“scdmaent”+2 

$FF 8C0D 

RAV 

DMA-Bytezähler (Low Byte) 

“scdmacnt”+4 

$FF 8C0F 

RAV 

DMA-Bytezähler (Lowest Byte) 

“scdmacnt”+6 


Auch hier kann für den Long-Zugriff auf diese Register in Maschinensprache ein “movep.I”- 
Befehl benutzt werden! 


Adresse 

Zugriff 

Bezeichnung 

Label 

SFF8C10 

R 

Restdatenregister (High-Word) 

“scdmarsd” 

$FF 8C12 

R 

Restdatenregister (Low-Word) 

“scdmarsd”+2 


Wenn am Schluß einer DMA-Operation kein voller Long mehr in den Speicher übertragen 
wurde, muß hier der Rest an Datenbytes “per Hand” ausgelesen und durch die CPU an die 
richtigen Adressen gebracht werden! Wie viele Restbytes das sind, erfährt man aus den letzten 
beiden Adreßbits des DMA-Address-Pointers. 

Die Startadresse n für die Restbytes ergibt sich aus dem Inhalt des DMA-Address-Pointers 
minus der Anzahl an Restbytes. Die Restbytes sind “linksbündig” im Restdatenregister ange¬ 
ordnet. Also gehört das Highbyte im High-Word an die Startadresse n. Das Lowbyte im High- 
word kommt nach Startadresse n+1 usw.! 


Adresse 

Zugriff 

Bezeichnung 

Labei 

$FF 8C14 

RAV 

Kontrollregister (Word) 

“scdmactl” 


Obwohl dieses Register mit Wordzugriffen bearbeitet wird, sind nur die untersten 8 Bit be¬ 
nutzt. Man kann deshalb auch mit Bytezugriffen auf die Adr. $(FF)FF 8C15 arbeiten, um diese 
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Kontrollbits zu beeinflussen bzw. auszuwerten. Hier deshalb nur die interessanten unteren 
8 Bits des Registers: 


Bit 7 

6 

5 

4 

3 

2 

1 

0 

Bus 

Error 

Byte 

count 

zero 

Reser¬ 

viert 

Reser¬ 

viert 

Reser¬ 

viert 

Reser¬ 

viert 

DMA 

Enable 

DMA- 

Direct¬ 

ion 


Bus Error Ein gesetztes Bit weist auf einen Busfehler während des DM A- 

Betriebs hin. Durch Auslesen dieses Registers wird der Bus¬ 
fehler-Status wieder zurückgesetzt. Diese Fehlersignalisierung 
geht auch an den TT-MFP, I/O-Port #2 und kann bei entspre¬ 
chender Programmierung einen Interrupt auslösen. 

Byte count zero Ein gesetztes Bit zeigt an, daß der DMA-Bytezähler auf Null 

gezählt hat, also alle Bytes transferiert sind. 


DMA-Enable 


Bei gesetztem Bit ist der DMA-Baustein “eingeschaltet*’. 


DMA-Direction Bit gesetzt: Schreiben an SCC-Controller. 

Bit gelöscht: Lesen von SCC-Controller. 


Um DMA-Betrieb durchzuführen, ist zunächst die Transferrichtung im DMA-Baustein (Bit 
0 in “scdmactl”) einzustellen. Anschließend wird die Basisadresse im DMA-Address-Pointer 
(“scdmabas”) gesetzt und die Zahl der zu übertragenden Bytes im DMA-Bytezähler 
(“scdmacnt”) eingestellt. 

Wenn dann auch der SCC-Controller entsprechend programmiert ist, wird durch Setzen des 
“DMA-Enable”-Bits in “scdmactl” der DMA-Prozeß gestartet. 


Die hardwaremäßige Einbindung des SCC beim TT 

Der Schaltungsauszug in der nachfolgenden Abbildung zeigt die hardwaremäßige Einbindung 
des SCC beim TT. Mittels des XLAN-Signals vom Soundchip kann der Kanal A des SCC 
softwaregesteuert auf den LAN-Anschluß oder den SERIAL 2-Anschluß (9pol. SubD- 
Buchse) geschaltet werden. Nach neuesten Infos plant ATARI aber hier eine Änderung, die 
diese Umschaltmöglichkeit evtl, nicht mehr enthält. Vielmehr soll der hierfür benutzte Sound¬ 
chip-Anschluß zusätzlich am Parallelport zur Verfügung gestellt werden, um eine einfachere 
Anschlußmöglichkeit für handelsübliche Scanner zu ermöglichen. 
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Abh. 7.8: Die hardwaremäßige Einbindung des SCC im TT 
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Initialisierung für Asynchronbetrieb (Poll-Betrieb) 

Nachfolgendes “Mini”-Listing zeigt eine Beispielinitialisierang, um beim TT/MEGA STE 
den SCC-Kanal B (Buchse MODEM 2) für Asynchronbetrieb mit 38400 Bit/s einzustellen. 

Dabei wird als Sende- und Empfangstakt der 2,4576 MHz-Takt der MFPs über den TRxCB- 
Anschluß dem SCC zugeführt. Durch Einstellung eines Verhältnisses von 64 Taktimpulsen 
pro Datenschritt ergibt sich eine Übertragungsgeschwindigkeit von 38400 Bit/s. 


; Beispielinitialisierung des SCC-Kanals B für Asynchronbetrieb 
; ohne Interrupts. Sender auf Empfänger "geschleift"! 

; Taktung erfolgt über TRxCB-Anschluß mit 2,4576 MHz-MFP-Takt. 

; Durch Takt/Datenrate = 64 ist eine Baudrate von 38400 Bd ein- 
; gestellt. 

; (H.-D. Jankowski / Juli '91 für ATARI TT/ST/STE Profibuch) 

sccctl_b equ $ffff8c85 ; Controlreg. für SCC-B 

sccdat_b equ $ffff8c87 ; Datenregister " SCC-B 


iniscc: 

lea 

lea 

lea 

move.w 
iniloop: 

move.b 
move.b 
dbra 
iniend: 


sccctl_b,aO 
sccdat_b,al 
initable,a2 
(a2) +, dl 

<a2)+,(aO) 
(a2)+,(aO) 
dl,iniloop 


; Pointer auf SCC-Kontrolreg. B 
; Pointer auf SCC-Datenreg. B 
; Zeiger auf Tabelle mit Ini.-Daten 
; Anzahl Tabelleneinträge 

; Initialisierungsdaten aus Tabelle 
; lesen und in SCC-B schreiben. 


; Diese kleine Routine liest lediglich die zu sendenden Zeichen 
; ab Adresse "sendtxt" ein und sendet sie über den SCC-B aus. 

; Da dieser im Schleifenbetrieb gefahren wird, können diese so 
; "ausgesendeten" Daten unmittelbar wieder eingelesen werden. 

; Es erfolgt z. B. keinerlei Fehlerabfrage! 

senden: 

lea sendtxt,a3 ; Zeiger auf Textanfang 
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recv: 


send: 


lea 

buffer,a4 

r 

Zielbuffer für empfangenen Text 

move, b 

(aO), dl 

r 

Read Register 0 auslesen 

btst 

#0, dl 

r 

Rx Buffer-Bit testen 

beq. s 

send 

F 

Mind. 1 Zeichen da? 

move.b 

(al), (a4) + 

r 

Ja! Zeichen holen. 

beq.s 

rcvend 

r 

Wenn Null empfangen wurde, raus 

move.b 

<a0),dl 

} 

Read Register 0 auslesen 

btst 

#2, dl 

i 

Tx Buffer empty-Bit testen 

beq.s 

recv 

r 

Sendebuffer leer? 

move.b 

bra.s 

(a3)+,(al) 

recv 

f 

Ja! Zeichen holen und ausgeben 


rcvend: 

rts 


■ data 


; Tabelle mit Initialisierungsdaten für SCC-Kanal B 
initable: 


dc.w 

9 

/ 

Anzahl Einträge in Ini.-Tabelle 

dc.b 

$09,$C0 

F 

Hardware-Reset ausführen 

dc.b 

$04,$CC 

F 

x64 Takt, 2 Stopbits, No Parity 

dc.b 

$03,$C0 

T 

Rx 8 Bits/Zeichen, Rx disabled 

dc.b 

$05,$60 

F 

Tx 8 Bits/Zeichen, DTR,RTS,Tx off 

dc.b 

$09,$00 

! 

Interrupts abgeschaltet 

dc.b 

$0A,$00 

F 

NRZ-Modus 

dc.b 

$0B,$28 

F 

Tx & Rx = TrxC = Input 

dc.b 

$0E,$10 

t 

BRG off, loopback 

sccenabl: 

dc.b 

$03,$C1 

/ 

Rx enable 

dc.b 

$05,$68 

r 

Tx enable 

sendtxt: 

dc.b 

'Dies ist der 

zu sendende Text!!!',0 

.bss 

buffer: 

ds .b 

50 

i 

Platz für 50 Empfangszeichen 
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Die Atari-Computer wurden immer wieder wegen fehlender Erweiterungsmöglichkeiten (z. 
B. durch Erweiterungskarten) kritisiert. Diesen Kritikpunkt hat Atari erstmals mit Vorstellung 
des MEGA ST aufgegriffen und eine Erweiterungsmöglichkeit durch den Megabus geschaf¬ 
fen (siehe dazu auch im ST-Teil im Kapitel “Die Zentraleinheit”). Hierbei handelte es sich 
letztlich um einen Anschluß, an dem alle MC68000er-Prozessorsignale zur Verfügung stehen. 

Beim TT/MEGA STE wollte man dann wohl eine einheitliche Linie finden und sich nicht auf 
die MC68000-Signale festbeißen (Schließlich hat man ja im TT auch eine CPU mit ganz 
anderen Möglichkeiten und z. T. auch anderem Signalverhalten vor sich). Fündig geworden 
ist Atari dann beim VME-Bus, der ein weitverbreiteter Standardbus in der Industrie ist. Zudem 
ähnelt das Verhalten der Steuer- und Quittungssignale sehr dem der Signale der Motorola- 
CPUs (was Wunder, schließlich kam die Initiative zu diesem Bussystem ja von dort). 

Also findet sich im TT/MEGA STE jetzt eine Anschlußmöglichkeit für Erweiterungskarten 
nach dem VME-Bus-Prinzip. Dazu werden von zwei 50pol. Pfostensteckverbindem auf der 
Hauptplatine die nötigen Signale über Flachbandkabel zu der beim VME-Bus verwendeten 
96pol. Federleiste nach DEN 41612, Bauform C, geführt. Im Gehäuse des Rechners ist Platz 
(so gerade!) für eine Einfach-Europakarte (100mm x 160mm). 


Das VME-Buskonzept 

Der VME-Bus unterstützt bei Einfach-Europakartenformat einen 24-Bit-Adreß- und einen 
16-Bit-Datenbus. Durch Übergang auf ein Doppel-Europakartenformat kann der Bus auf volle 
32 Bit für den Adreß- und Datenbereich erweitert werden. Dabei werden Uber den dann 
zusätzlich erforderlichen Steckverbinder lediglich die noch fehlenden Adreß- und Daten¬ 
bussignale geführt. Alle anderen Signale sind bereits auf der Einfach-Europakartenversion 
verfügbar. Der gesamte VME-Bus gliedert sich dabei in vier Teilsysteme: 

- Der Daten-Transfer-Bus (DTB) verfügt über alle Daten- und Adreßleitungen sowie die 
für den Datentransfer erforderlichen Steuer- und Quittungsleitungen. 

- Über den Arbitrations-Bus laufen alle für die Steuerung eines Multi-Master-Systems 
notwendigen Signale. 


Der Interrupt-Bus stellt die Signal wege für die Behandlung von Unterbrechungen zur 
Verfügung. 
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Versorgungs- und Hilfsleitungen bilden die restlichen Signale zur Stromversorgung und 
Fehlererkennung. 


Die Steckerbelegung des 96pol. VME-Bus-Steckers zeigt die nachfolgende Liste. 


Alle mit einem beginnenden Signale sind low-aktiv! 


Pin-Nr. 

Reihe a 

Reihe b 

Reihe c 

1 

DO 

J3BSY 

D8 

2 

Dl 

J3CLR 

D9 

3 

D2 

_ACFA1L 

D10 

4 

D3 

.BGOIN 

Dil 

5 

D4 

J3G0OUT 

D12 

6 

D5 

JBG1IN 

D13 

7 

D6 

_bgiout 

D14 

8 

D7 

_BG2IN 

D15 

9 

GND 

_BG20UT 

GND 

10 

SYSCLK 

J3G3IN 

_SYSFAIL 

11 

GND 

J3G30UT 

_berr 

12 

_DS1 

„BRO 

_SYSRESET 

13 

_DS0 

_BR1 

JAVORD 

14 

_WRITE 

_BR2 

_AM5 

15 

GND 

J3R3 

A23 

16 

JDTACK 

AMO 

A22 

17 

GND 

AMI 

A21 

18 

_AS 

AM2 

A20 

19 

GND 

AM3 

A19 

20 

JACK 

GND 

A18 

21 

JACKIN 

SERCLK 

A17 

22 

JACKOUT 

SERDAT 

A16 

23 

AM4 

GND 

A15 

24 

A7 

JRQ7 

A14 

25 

A6 

JRQ6 

A13 

26 

A5 

JRQ5 

A12 

27 

A4 

JRQ4 

All 

28 

A3 

JRQ3 

A10 

29 

A2 

JRQ2 

A9 

30 

Al 

JRQ1 

A8 

31 

-12 V 

+5V (Stand By) 

+12V 

32 

+5V 

+5V 

+5V 
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Daten-Transfer-Bus (DTB) 

Der DTB wird asynchron betrieben, um auch Devices mit unterschiedlichen Geschwindigkei¬ 
ten am Bus betreiben zu können. Adreß- und Datenbus sind nicht gemultiplext. 

Der Datentransfer zwischen Sender (Master) und Empfänger (Slave) läuft nach folgendem 
Schema ab: 

- Die Gültigkeit einer Adreßinformation auf dem Bus signalisiert der Master durch Akti¬ 
vierung von Address Strobe (_AS). 

- Über das „WRITE-Signal erfährt der Slave, ob gelesen („WRITE=High) oder geschrie¬ 
ben wird. 



Ahb. 8.1: Byte-Lesezyklus auf dem Daten-Transfer-Bus 
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- Bei einem Lesezugriff wird dem Slave über die beiden Data-Strobe-Leitungen _DS0 und 
_DS1 mitgeteilt, wenn der Master zum Einlesen der Daten bereit ist! 

Für einen Schreibzugriff werden vom Master zunächst die Daten auf den Datenbus 
plaziert und anschließend diese über _DS0 und „DS1 als “gültig” erklärt. 

- Der Bus wird vom Master erst wieder freigegeben, wenn vom Slave ein _DTACK (Data 
Transfer Acknowledge) empfangen wurde. Der Slave ‘ ‘fühlt” sich so lange an den Master 
gebunden (und gibt den Bus so lange auch nicht frei!), wie der nicht _DS0 und _DS1 
wieder deaktiviert hat. 

Wenn der Slave sich “nicht in der Lage sieht”, die Schreib-ZLeseanforderung korrekt aus¬ 
zuführen, aktiviert er statt _DTACK das Bus-Error-Signal (_BERR). Als Reaktion 
darauf wechselt der Master in eine entsprechende Fehlerbehandlungsroutine. 

Da über den Datentransferbus sowohl Byte-, Word- (16 Bit) und auch Langwort-Zugriffe 
(32 Bit) abgewickelt werden können, ist eine entsprechende Signalisierung der Zugriffsart 
erforderlich. Diese erfolgt über die Signale _DS0 (Low-Byte) und __DS 1 (High-Byte) und bei 
Langwort-Zugriffen noch zusätzlich durch das _LWORD-Signal. Zusätzlich zu den Adreßlei¬ 
tungen existieren zur Adreßverwaltung noch sechs ”Address-Modifier”-Leitungen AMO.. AM5. 
Diese zeigen das gleiche Zeitverhalten wie die Adreßleitungen und liefern zusätzliche Infor¬ 
mationen über die anliegende Adresse. Folgende Anwendungsfälle lassen sich damit signa¬ 
lisieren: 

- Durch entsprechende AM-Codes werden drei Adreßbereiche unterschieden: 

Extended Access = Zugriff auf den vollen 32 Bit-Bereich 
Standard Access = Zugriff auf einen 24 Bit-Bereich 
Short-Access = Zugriff auf einen 16 Bit-Bereich 

Speicherzugriffe werden durch entsprechende AM-Codes in Supervisor- und User- 
Speicherbereiche unterschieden, wie man das ja schon von den Motorola-CPUs her 
kennt. 

- Unterscheidung des Speichers in Daten- und Programmbereich. 

Signalisierung, ob Speicher- oder E/A-Zugriff (Memory-Mapped I/O!) stattfindet. 

- Spezielle Formen des Speicherzugriffs, indem vom Master nur die Beginnadresse des 
anzusprechenden Speicherbereichs geliefert wird und die darauf folgenden Adressen 
durch Inkrementieren der Adresse auf dem Slave selbst angesteuert werden. 
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Die nachfolgende Tabelle zeigt die Werte für die Address-Modifier und die damit ausgewählte 
Funktion. 


AM-Code in 


Hex. 

Binär 

Funktion 

3F 

111111 

Standard-Supervisory-Zugriff, Inkrementeil 

3E 

111110 

Standard-Supervisory-Zugriff, Programmbereich 

3D 

11110 1 

Standard-Supervisory-Zugriff, Datenbereich 

3B 

1110 11 

Standard-User-Zugriff, Inkrementell 

3A 

1110 10 

Standard-User-Zugriff, Programmbereich 

39 

1110 0 1 

Standard-User-Zugriff, Datenbereich 

2D 

10 110 1 

Short-Supervisory-Zugriff, E/A-Bereich 

29 

l 0 1 0 0 1 

Short-User-Zugriff, E/A-Bereich 

OF 

0 0 1111 

Extended-Supervisory-Zugriff, Inkrementell 

OE 

0 0 1110 

Extended-Supervisory-Zugriff, Programmbereich 

OD 

0 0 110 1 

Extended-Supervisory-Zugriff, Datenbereich 

OB 

0 0 10 11 

Extended-User-Zugriff, Inkrementell 

OA 

0 0 10 10 

Extended-User-Zugriff, Programmbereich 

09 

0 0 1 0 0 1 

Extended-User-Zugriff, Datenbereich 


Die nicht aufgeführten AM-Codes sind reserviert! 


Der Arbitrations-Bus 

Damit in einem Multiprozessorsystem mehrere Master auf den DTB zugreifen können, muß 
eine gewisse Absprache zwischen den Mastem für die Busbenutzung erfolgen. Es wird also 
entschieden (= to arbitrate), welcher Master jeweils den Bus benutzen darf. 

Dafür gibt es in Multiprozessorsystemen einen eigenen “Schiedsrichter”, den Arbiter. 

Die Anforderung des Busses nimmt ein Master über eine der vier Bus-Request-Leitungen 
(_BR0.._BR3) vor. Jeder dieser vier Request-Leitungen ist eine eigene Priorität zugeordnet 
(_BR3 ist höchste Priorität). Der Arbiter vergleicht die Priorität des anfordemden Masters mit 
der Priorität des Masters, der gerade den Bus kontrolliert. 

Hat der anfordemde Master eine höhere Priorität, sendet der Arbiter ein Bus-Clear-Signal 
(„BCIJR), um den gegenwärtigen Busmaster zur schnellstmöglichen Freigabe des Busses 
aufzufordem. Dieser reagiert darauf zum nächstmöglichen Zeitpunkt (üblicherweise nach 
Beendigung des gegenwärtigen Buszyklusses) durch Deaktivierung von Bus-Busy (JBBSY). 
Der Arbiter sendet daraufhin der Einheit mit der höchsten anstehenden Priorität ein Bus- 
Freigabe-Signal (Bus-Grant = JBG0.._BG3) und deaktiviert _BCLR. 
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Wenn der anfordemde Master niedriger priorisiert ist als der gegenwärtige Busmaster, wird 
die Busanforderung erst bedient, wenn der Bus frei ist! 

Weil nach diesem Schema nur vier Busmaster vom Arbiter verwaltet werden können, hat man 
noch eine zusätzliche Prioritätsebene vorgesehen. Man verwendet hier das Prinzip des “Daisy- 
chaining”, der Prioritätsverkettung. Das bedeutet in der Praxis, daß der physikalisch am 
nächsten zum Arbiter gelegene Master, mit ansonsten gleicher Priorität, “bevorzugter” 
behandelt wird! Mit wachsender Entfernung nimmt die “Bevorzugung” ab. Jede der vier 
Anforderungsebenen BRO. ,_BR3 hat eine eigene “Daisy-Chain”. In der Praxis sieht das dann 
so aus, daß das Busfreigabe-Signal _BG, welches dem Bus anfordemden Master die 
“Herrschaft” über den Bus zuweist, vom Arbiter zum_BG#IN-Anschluß des nächstgelegenen 
Masters geführt wird. Wenn dieser den Bus belegen will, gibt er das Busfreigabe-Signal JBG 
nicht weiter; andernfalls aktiviert er _BG#OUT, was dann zu _BG#IN des nächsten Masters 
führt usw. Mittels dieser Technik können beliebig viele Master auf dem VME-Bus Zusammen¬ 
arbeiten. 
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Abb. 8.2: Block-Diagramm zur Bus-Arbitration 


Der Interrupt-Bus 

Auch hier wird, wie beim Arbitrations-Bus, mit unterschiedlichen Prioritäten gearbeitet. Auf 
dem VME-Bus wird zur Auswahl der Interrupt-Service-Routine im Interrupt-Handler mit 
Interruptvektoren gearbeitet. Die Interrupt-Anforderung erfolgt über sieben Interrupt-Request- 
Leitungen _IRQ7. -_IRQ 1, wobei _IRQ7 die höchste Priorität zugeordnet ist. Mit entsprechen¬ 
der Maskierung (z. B. durch eine Interruptmaske bei MC680XX-Prozessoren) entscheidet der 
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Interrupthandler, ob der Interrupt zugelassen wird oder nicht. Um auch bei nur sieben IRQ- 
Ebenen eine beliebige Anzahl von Interruptquellen gewichten zu können, kann wieder mit der 
schon beim Arbitrations-Bus geschilderten “Daisy-Chain”-Technik gearbeitet werden. Dazu 
wird das Interrupt-Erkennungssignal desInterrupthandlersvonModulzuModul weitergereicht 
(an _IACKIN rein und bei JACKOUT wieder raus zum nächsten Modul!), bis es bei jenem 
Modul angekommen ist, dessen Interrupt-Anforderung bearbeitet werden soll. 

Die Interrupt-Erkennung erfolgt durch den Interrupt-Handler unter Benutzung des DTB, den 
der Int.-Handler sich dazu evtl, vorher vom Arbiter “zuteilen” lassen muß! Wenn der Int.- 
Handler den DTB “hat”, aktiviert er Interrupt-Acknowledge (JACK) und legt den Interrupt- 
Anforderungskode (Priorität von 1 ..7) auf A1.. A3 des Adreßbusses. Der nun folgende, norma- 
leLesezyklusliefertdannvon demModul,dasdenInterruptangeforderthat,dieVektomurnrner. 



(7) t (it-i) vom Inleiruptrequester/Interrupthandler 
v garantiertes Zeitvnrhalten 

* Low (niedriger Pegel) ist aktiver Zustand 


Abb. 8.3: Zeitverhalten der Interrupterkennung 
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Diese Vektomummer darf aber erst auf den Datenbus (Low-Byte, _DS0 aktiviert, _DS1 
nicht!) ausgegeben werden, wenn das den Interrupt anfordemde Modul auch das Signal 
JACK des Interrupt-Handlers an seinen JACKIN-Anschluß über die “Daisy-Chain” emp¬ 
fangen hat. Die Interrupt-Sefvice-Routine wird im Interrupt-Handler über die Vektomummer 
berechnet und enthält die zur Interrupt-Bearbeitung nötigen Befehle. 


Die Hills- und Versorgungsleitungen 

Neben den Versorgungsspannungen werden über diesen Teil des VME-Busses noch einige 
weitere Hilfssignale für die Initialisierung, Synchronisation und zur Fehlerdiagnose geführt. 

SYSCLK ist ein 16 MHz-Takt, der nicht mit dem Prozessortakt synchron sein muß. Dieses 
Signal kann z. B. für Zähleranwendungen herangezogen werden. 

SYSRESEI' dient dem Rückstellen aller Systemmodus in einen definierten Anfangszustand. 
Es kann manuell oder vom Netzteil gesteuert aktiviert werden. 

SYSFAIL kann einen Fehler im System melden. So kann ein Modul nach einem Systemreset 
und einem durchgeführten (fehlerhaften) Selbsttest _S YSFAIL nicht wieder deaktivieren und 
so einen Fehlerzustand melden. 

ACFA1L signalisiert einen Fehler in der Spannungsversorgung (Spannungseinbruch). Damit 
bleibt dem System laut VME-Bus-Spezifikation noch mindestens 4ms für eine ordnungsge¬ 
mäße Abbruch-Bearbeitung. 


Einschränkungen beim VME-Busanschluß des TT/MEGA STE 

ATARI verspricht Kompatibilität zum VME-Bus-Standard, jedoch mit einigen Ausnahmen. 

Bus-Arbitration wird nicht unterstützt! Alle Bus-Request-Signale _BR0.._BK3 sind auf 
dem Motherboard miteinander verbunden und mit einem 1K£2 Pull-up-Widerstand an 
+5V “gebunden”. Gleiches gilt auch für die ,_BG0IN.._BG3IN-Signale! _BBSY und 
_BCLR liegen ebenfalls jeweils über 1KQ an +5 V und werden anderweitig nicht benutzt. 

- Der serielle Bus mit SERCLK und _SERDAT ist nicht vorhanden. 

- _SYSCLK wird mit dem 16,107953 MHz-Systemtakt gespeist. 

- _ACFAIL ist low, solange die Spannungsversorgung nach dem Einschalten noch nicht 
stabil läuft. ATARI verspricht 1ms vor dem Verlassen der gültigen Spannungsbereiche 
eine Aktivierung von _ACFAIL. Das Signal ist mit 1K£2 gegen +5V geschaltet. 
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J5YSRESET ist direkt mit dem RESET-Signal des Motherboards verbunden (1,2KQ- 
Pull-up-Widerstand gegen +5 V). Es kann sowohl vom Motherboard (z. B. CPU) als auch 
von einer VME-Bus-Karte aktiviert werden. 

- _BERR ist ebenfalls direkt mit dem Bus-Error-Signal des Motherboards verbunden 
(1,2KQ-Pull-up-Widerstand gegen +5V). “Sieht” die Überwachungsschaltung (in der 
SCU) auf dem Motherboard 255 Taktzyklen (16 MHz-Takt!) nach Aktivierung von 
_AS kein JOTACK, wird ein Bus-Error ausgelöst! 

- ATARI verwendet aktiv nur die Address-Modifier AMO, AMI, AM2 und AM4. AM3 
und AM5 liegen über 1 KO-Widerstände an +5V. Damit ist alles bis auf Extended- 
Zugriffe möglich. Inkrementelle Zugriffe (Blockzugriffe) werden aber nicht unterstützt! 
Da nur ein 16 Bit-Datenbus am ATARI-VME-Bus zur Verfügung steht, wird das 
JJWORD-Signal nicht benötigt. Es ist mit 1KO gegen +5V abgeschlossen. 

Im TT030 findet sich für Standard-Zugriffe (24 Bit!) der VME-Bus-Adreßraum bei 
$FE00 0000..$FEFEFFFF.FürShort-ZugriffeliegtderAdreßbereichbei$FEFF 0000.. 
$FEFF FFFF. Im MEGA STE liegt der 24 Bit-Adreßraum bei $ A0 0000 bis $DE FFFF. 
Short-Zugriffe “landen” im MEGA STE bei $DF 0000..$DF FFFF. 

- Die Interrupt-Request Signale JRQ1 ..JRQ7 sind auf dem Motherboard mit je einem 
1 KO-Widerstand gegen +5V abgeschlossen und können verwendet werden. JRQ3, 
_IRQ5 und _IRQ6 können auch vom Motherboard aktiviert werden. Ein Level-7- 
Interrupt kann durch das JSYSFAIL-Signal (mit IKO-Pull-up auf Motherboard abge¬ 
schlossen!) einer VME-Bus-Karte ausgelöst werden. JACK und JACKIN werden vom 
Motherboard gesteuert und sollten deshalb nicht von einer Karte angesteuert werden 
(TT/MEGA STE ist Interrupthandler!). Das JACKOUT-Signal wird nicht verwendet. 

Der Interrupt-Vektor, welcher während des Interrupt-Acknowledge-Zyklus von einer 
VME-Bus-Karte geliefert wird, ist gleichzeitig Interrupt-Vektor für die System-CPU! 
Atari hat den Vektor $FF für sich reserviert! Für Drittanbieter empfiehlt Atari die Inter¬ 
rupt-Vektoren von $80..$BF und damit die Vektor-Adressen $200..$2FF. Alle VME- 
Bus- und System-Interrupts sind unabhängig voneinander in der System Control Unit 
(SCU) maskierbar. 

Dann gilt noch für alle Ausgänge, daß sie mindestens 1 LS-TTL-Eingänge treiben können 
(was nicht das meiste ist!). Eingänge am TT/MEGA STE belasten den VME-Bus mit nicht 
mehr als 2 LS-TTL-Eingangslasten. Die Stromversorgungsanschlüsse des VME-Bus-An- 
schlusses haben folgende “Reserven”: 

+5V bei max. 2A 
+12V bei max. 50mA 
-12V bei max. 50mA 



























































Kapitel 9: Die System Control Unit 
im TT/MEGA STE 


Zur Überwachung des Systems auf Bus-Errors/Interrupts und zur Erzeugung einiger Chip- 
Select-Signale (MFPs und FPU) hat ATARI im TT/MEGA STE einen eigenen Custom-Chip 
eingesetzt, die System Control Unit (SCU). Die wichtigste Funktion der SCU im System dürfte 
wohl die Verwaltung der Interrupts sein. Im Gegensatz zum ST existieren ja bei den neuen 
Maschinen mit VME-Bus-Anschluß einige Interruptquellen mehr, die verwaltet werden müs¬ 
sen. Außerdem verfügt die SCU noch über einige Register, durch deren Beschreiben Interrupts 
softwaregesteuert ausgelöst werden können. 


Interrupts unter Kontrolle 

Die SCU besitzt zwei voneinander unabhängige Mask-Register, über die einstellbar ist, 
weicher Interrupt-Level überhaupt bis zur CPU durchdringt. 


Systemboard-Interrupts 

Dabei maskiert das “sys_mask”-Register die Interrupt-Anforderungen vom Systemboard. 
Dazu gehört ein “sys_stat”-Register, in dem die Interrupt-Anforderungen vom Systemboard 
“bereitgehalten” werden. Die Bits dieses Registers zeigen den jeweiligen Zustand der sieben 
möglichen Interrupt-Anforderungen an. An dieser Stelle ist die Maskierung noch nicht wirk¬ 
sam, d. h. alle Interruptanforderungen setzen ihr zugehöriges Bit! 


Adresse 

Zugriff 

Funktion 

Label 

$FF 8E01 

RAV 

| System Int. Mask-Register 

“sys_mask” 


Das BitO des Registers wird nicht verwendet. Die Bits 7.. I bilden die Maske für die 
Systeminterrupts. Ein gesetztes Bit zeigt an, daß der zugehörige Interrupt entsprechender 
Priorität an die CPU weitergereicht wird. Bei gelöschtem Bit unterbleibt eine Interrupt¬ 
anforderung an die CPU. Folgende Systeminterruptquellen sind vorgesehen: 


Int.-Level 

Interrupt-Quelle 

Interrupt-Vektor 

7 

JSYSFAIL von VME-Bus 

Autovektor 

6 

IRQ von MFPs 

Programmierbar 

5 

IRQ von SCC 

Programmierbar 
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Int.-Level 

Interrupt-Quelle 

Interrupt-Vektor 

4 

VSYNC 

Autovektor 

3 

Nicht vorhanden 

- 

2 

HSYNC 

Autovektor 

1 

System Software-Interrupt 

Autovektor 


Im TOS 3.01 wird das “sys_mask”-Register mit dem Wert $14 initialisiert. Also sind alle 
Interrupt-Requests bis auf VSYNC und HSYNC maskiert! 


Adresse 

Zugriff 

Funktion 

Label 

$FF 8E03 

R 

System Int. Status-Register 

“sys_stat” 


Auch hier wird das Bit 0 nicht verwendet. Die anderen Bits stellen direkt den jeweiligen Status 
der IRQ-Anforderungen dar (gesetztes Bit = IRQ liegt vor), ohne die Maskierung durch das 
“sys_mask”-Register zu berücksichtigen. Dabei gilt die gleiche Zuordnung, wie bereits beim 
“sys_mask”-Register gezeigt. Dieses Register sollte vor einem Zugriff auf das “sys_mask”- 
Register ausgelesen werden, da ein Zugriff auf das Mask-Register die Interrupt-Requests im 
“sys_stat”-Register zurücksetzt! 


VME-Bus-Interrupts 

Für Interrupts vom VME-Bus existiert so ein Registersatz ebenfalls (“vme_mask” und 
“vme_stat”). Dabei ist allerdings zu beachten, daß die System-Interruptanforderungen 5 und 
6 auch auf die entsprechenden IRQ-Leitungen des VME-Busses aufgeschal tet sind und somit 
noch zusätzlich als Interrupt-Requests im “vme_stat”-Register anstehen! 

Damit wird erreicht, daß ein entsprechender VME-Bus-Master diese Systeminterrupts 
ebenfalls “bemerkt” und abarbeiten kann! Es bedeutet aber auch, daß diese System-Interrupts 
für die CPU wie VME-Bus-Interrupts “aussehen” und nicht durch ausschließliches Maskieren 
im “sys_mask”-Register “unwirksam” gemacht werden können. 

Ferner läßt sich vom System softwaremäßig ein Interrupt erzeugen, der als _IRQ3 auf dem 
VME-Bus erscheint. Dieser Interrupt-Request wird natürlich ebenfalls im “vme_stat”-Regi- 
ster “bemerkt” und kann im “vme_mask”-Register maskiert werden! 


Adresse 

Zugriff 

Funktion 

Label 

$FF 8E0D 

R/W 

VME-Bus Int. Mask-Register 

“vmejmask” 
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Das Bit 0 des Registers wird wieder nicht verwendet. Die Bits 7.. 1 bilden die Maske für die 
VME-Bus-Interrupts. Ein gesetztes Bit zeigt an, daß der zugehörige Interrupt entsprechender 
Priorität an die CPU weitergereicht wird. 

Bei gelöschtem Bit unterbleibt eine Interruptanforderung an die CPU. 

Folgende VME-Bus-Interruptquellen sind vorgesehen: 


Int.-Level 

Interrupt-Quelle 

Interrupt-Vektor 

7 

_IRQ7 von VME-Bus 

Programmierbar 

6 

JGRQ6 von VME-Bus bzw. IRQ von MFPs 

Programmierbar 

5 

_IRQ5 von VME-Bus bzw. IRQ von SCC 

Programmierbar 

4 

J0RQ4 von VME-Bus 

Programmierbar 

3 

_IRQ3 von VME-Bus bzw. durch Software 

Progr./Autovek. 

2 

_IRQ2 von VME-Bus 

Programmierbar 

1 

_IRQ1 von VME-Bus 

Programmierbar 


Im TOS 3.01 wird dieses Register mit $60 initialisiert. Damit sind also nur der _IRQ6 (MFP- 
IRQ) und der _IRQ5 (SCC-IRQ) freigegeben! 


Adresse 

Zugriff 

Funktion 

Label 

$FF 8E0F 

R 

VME-Bus Int. Status-Register 

“vme_stat” 


Bit 0 ist wieder nicht verwendet. Die anderen Bits stellen wieder den jeweiligen Status der 
IRQ-Anforderungen dar, ohne eine evtl. Maskierung durch das “vme_mask”-Register zu 
berücksichtigen. Es gilt die gleiche Zuordnung, wie beim “vme_mask”-Register gezeigt. 
Dieses Register sollte vor einem Zugriff auf das “vme_mask”-Register ausgelesen werden, 
da ein Zugriff auf das Mask-Register die Interrupt-Requests im “vme_stat”-Register zurück¬ 
setzt! 


Software-Interrupts durch die SCU 

Die SCU besitzt zwei Register, durch deren Beschreiben ein Interrupt ausgelöst werden kann. 
Beide Interrupts werden als Autovektor-Interrupts entsprechender Priorität behandelt. 


Adresse 

Zugriff 

Funktion 

Label 

$FF 8E05 

RAV 

System-Software-Int. erzeugen 

“sysjnt" 
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Setzt man durch Einschreiben in dieses Register das Bit 0, wird ein System-Interrupt-Request 
der Priorität 1 ausgelöst. Dieser gelangt natürlich nur zur CPU, wenn er nicht in “sys_mask” 
ausmaskiert ist. Der Pointer auf die Autovektor-Serviceroutine für diesen Interrupt steht im 
RAM in Adresse $64. 


Adresse 

Zugriff 

Funktion 

Label 

$FF 8E07 

RAV 

VME-Bus-IRQ Level 3 erzeugen 

“vmejnt” 



Abb. 9,1: Die Einbindung der SCU im TTIMEGA STE 
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Durch Einschreiben einer $01 in dieses Register wird ein System-Interrupt-Request der Prio¬ 
rität 3 auf dem VME-Bus ausgelöst. Dazu muß aber im “sys_mask”-Register der IRQ 3 freige¬ 
geben sein! Der Pointer auf die zugehörige Autovektor-Serviceroutine muß dann im RAM in 
Adresse $6C stehen. 

Generell gilt für die Interrupt-Behandlung durch die SCU, daß bei Interrupt-Requests gleicher 
Priorität vom Systemboard und vom VME-Bus der Systeminterrupt höher priorisiert ist! 


Sonstige Register in der SCU 

Die SCU verfügt noch über zwei Universal-Register, die z. B. zur Speicherung von Konfigu¬ 
rationswerten für das System benutzt werden können. Diese Register sind 8 Bit breit und an 
folgenden Adressen zu finden: 


Adresse 

Zugriff 

Funktion 

Label 

$FF 8E09 

RAV 

SCU General Purpose Reg. 1 

“scu _gpl” 

$FF 8E0B 

RAV 

SCU General Purpose Reg. 2 

“scu_gp2” 


Bei einem System-RESET werden alle SCU-Register gelöscht! 




Kapitel 10: Der Uhrenchip im TT 


Im TT verwendet ATARI einen anderen Uhrenchip als im MEGA ST/MEGA STE. Bei 
diesem Uhrenchip sind zusätzlich zu den Zeit- und Datumsfunktionen noch 50 Bytes an 
batteriegepuffertem RAM nutzbar. Darin lassen sich zum Beispiel Initialisierungswerte 
ablegen, die auch nach dem Ausschalten des Systems nicht vergessen werden. Zur “Verwal¬ 
tung” dieses “alternativen Speicherbereichs” hat ATARI sogar eigene Betriebssystemauffufe 
bereitgestellt. 

Verwendet wird der Motorola-Uhrenchip MC 146818A, der sich sowohl in Mo-torola- als auch 
in Intel-Prozessor-Umgebungen betreiben läßt. Die Betriebsart wird über den Pin 1 (MOT) 
eingestellt. 

Eine 6V-Batterie sorgt für das “Überleben” der Daten bei ausgeschaltetem Rechner. Damit 
der Takt für den “Wecker” bei ausgeschaltetem Rechner nicht stehenbleibt, wird ein eigener 
Oszillator (auch durch Batterie gepuffert) mit einer Frequenz von 32,768 kHz benutzt. 



Abb. 10.1: Die hardwaremäßige Einbindung des TT-Uhrenchips 
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Ähnlich dem “alten” Uhrenchip z. B. im MEGA ST besitzt auch dieser Chip einen Recht¬ 
ecksignal-Ausgang, bei dem die Ausgangsfrequenz softwaremäßig eingestellt werden kann. 
Aber auch im TT verwendet Atari diesen Ausgang nicht. Der Anschluß aber, der diesmal be¬ 
nutzt wird, ist der _IRQ-Anschluß des Chips, der unter bestimmten Bedingungen Interrupts 
auslösen kann (z. B. “Weckzeit erreicht”!). Im TT läuft der Low-Aktive Intenruptausgang des 
Uhrenchips an Port 16 des TT-MFP auf und kann abgefragt werden oder einen Interrupt aus¬ 
lösen. 

Zugriffe auf das RAM und die Uhrenregister erfolgen als Bytezugriffe ähnlich wie beim 
Soundchip in zwei Stufen. Zuerst wird das gewünschte Register durch Einschreiben der Regi- 
stemummer in “rtc_mr” ausgewählt. Anschließend kann über “rtc_data” das zuvor adressierte 
Register angesprochen werden. Nachfolgend die Adressen der beiden Uhrenregister (angege¬ 
ben ist nur die Lage im ST-Adreßraum; weiter “oben”, also bei $FFFF 896X, sind sie noch 
einmal zu finden!): 


Adresse 

Zugriff 

Funktion 

Label 

$FF 8961 

R/W 

Registerauswahl im Uhrenchip 

“rtc_mr” 

$FF 8963 

R/W 

Daten des selekt. Uhrenregisters 

“rtc_data” 


Die Register des Uhrenchips 

Neben 50 Bytes an batteriegepuffertem RAM existieren noch 14 weitere Uhrenregister zur 
Darstellung der Uhrzeit/Datums und für z. B. Alarmzeit/Statusbits. Die Registerbelegung des 
Chips zeigt die Abbildung 10.2. 


Die Zeit- und Datumsregister 

Dabei gilt sowohl für die Uhrzeit/Datumsregister als auch für die Alarmzeitregister, daß die 
Werte im Binärformat oder im BCD-Format verwendet werden können. Die Einstellung, 
welches Format benutzt wird, ist über das “DM”-Bit (Bit 2) in Register $0B vorzunehmen 
(Gelöscht = BCD-Format). Das Datenformat kann nicht während des Betriebs geändert wer¬ 
den, ohne eine Neuinitialisierung der Uhrenregister vorzunehmen! Das TOS arbeitet mit dem 
Binärformat. 

Außerdem läßt sich über das “24/12”-Bit (Bit 1) im Register $0B festlegen, ob die Zeit im 24- 
Stunden oder 12-Stunden-Format mit AM/PM-Signalisierung dargestellt wird. Wenn das “24/ 
12”-Bit gesetzt ist, wird der 24-Stunden-Modus benutzt, den auch das TOS verwendet. Falls 
mit 12-Stunden-Darstellung gearbeitet wird, erfolgt die AM/PM-Unterscheidung über das 
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Abb. 10.2: Die Register des TT-Uhrenchips 


höchstwertige Bitder Stundenregister (ZeitundAlarmzeit!),PM-Zeiten(~Nachmittagszeiten) 
werden durch ein gesetztes Bit 7 in den Stundenregistem (Zeit als auch Alarmzeit!) kenntlich 
gemacht! 


Alarmzeitregister 

Mit Hilfe der drei Alarmzeitregister kann eingestellt werden, wann eine Alarmsignalisierung 
(evtl, auch per Interrupt) erfolgen soll. Sobald Alarmzeit und aktuelle Zeit übereinstimmen, 
wird ein Alarmflag (“AF”-Bit = Bit 5 in Register $0C) gesetzt und abhängig von einem 
Enable-Bit (“AIE”-Bit = Bit 5 in Register $0B) ein Interrupt ausgelöst. Damit läßt sich eine 
tägliche Alarmsignalisierung erreichen. 

Über bestimmte “Don’t care”-Werte (alle Hex-Werte von $C0,.$FF sind solche “Don’t care”- 
Codes!) in den Alarmzeit-Registem lassen sich aber z. B. auch stündliche, minütliche oder so¬ 
gar sekundliche Alarmsignalisierungen erreichen. Eine “Don’t care”-Kombination bei den 
Alarmzeit-Stunden erzeugt jede Stunde eine Alarmierung. Bei “Don’t care” in Alarmzeit- 
Stunden und -Minuten “kommt” der Alarm jede Minute. Wenn alle drei Alarmzeit-Register 
mit “Don’t care”-Codes versehen sind, erfolgt jede Sekunde eine Alarmierung. 


Die Kontrollregister des Uhrenchips 

Mit Hilfe von vier Kontrollregistem ($0A..$0D) läßt sich das Verhalten des Uhrenchips be¬ 
einflussen und auswerten. Im Gegensatz zu den Registern $00..$09 sind diese vier Register 
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auch während des sogenannten “Update-Zyklus” erreichbar. Während des jede Sekunde 
einmal stattfindenden Update-Zyklus erfolgt im Uhrenchip die “Weiterschaltung” der Zeit- 
und Datumsregister und deren Vergleich mit den Alarmzeitregistem. 

Während dieser Zeit (maximal 2ms) sind die Register $00..$09 des Uhrenchips intern abge¬ 
koppelt, und ein Lesezugriff darauf liefert keine korrekten Werte! 

Um den richtigen Zeitpunkt für einen Zugriff auf die unteren zehn Uhrenregister zu “erwi¬ 
schen”, gibt es mehrere Möglichkeiten. 

Am Ende eines jeden Updates kann ein Interrupt ausgelöst werden. Wenn dieser “Update 
ended’ -Interrupt aufgetreten ist, hat man anschließend genug Zeit (min. 998ms!), um die 
gewünschten Register anzusprechen. 

Eine weitere Möglichkeit liegt in der Abfrage des “Update in Progress”-Bits (UIP-Bit 
= Bit 7 in Register $0A). Bei gesetztem Bit sollten die Zeit-/Datums-Register “in Ruhe 
gelassen werden”. 

Wenn das Bit einen Wert von Null aufweist, hat man mindestens noch 244us “Zeit” bis 
zum nächsten Update-Zyklus. 

Register $0A 

Die Bitbelegung dieses Registers und deren Bedeutung zeigt nachfolgende Tabelle: 


Bit 7 

Bit 6 

Bit 5 

Bit 4 

Bit "3 

Bit 2 

Bit 1 

BitO 

UIP 

DV2 

DV1 

DVO 

RS3 

RS2 

RS1 

RSO 


UIP Update in Progress Ein gesetztes Bit zeigt einen laufenden oder kurz bevorstehen¬ 
den Update-Zyklus der Zeit-/Datumsregister an, während dem 
ein Zugriff auf diese Register keine korrekten Werte liefert. 

Bei gelöschtem Bit sind noch mindestens 244ps Zeit bis zum 
nächsten Update. Dieses Bit kann nur gelesen werden! 

DV2, DV1, DVO Divider-Steuerbits 

Diese drei Bits werden dem Takt des Uhrenchips entsprechend 
festgelegt. Davon ist nämlich die Programmierung der Teiler¬ 
stufen für die Erzeugung des Sekundentakts abhängig. 
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Taktfrequenz 

! ' 

DV2 

i 

DV1 

' 

DV0 

Teiler in 
Betrieb 

Teiler 

Reset 

4,194304 MHz 

0 

0 

0 

Ja 

_ 

1,048576 MHz 

0 

0 

1 

Ja 

- 

32,768 kHz 

0 

1 1 

0 

Ja 

- 

Egal 

1 

1 

0 

Nein 

Ja 

Egal 

1 

1 

1 

Nein 

Ja 


Andere Bitkombinationen sind nicht zulässig! 

Da Atari mit einem 32,768 kHz-Takt arbeitet, werden die D V- 
Bits auf “010” gesetzt, 

RS3, RS2, RS1, RSO Rate-Select-Bits 

Über diese vier Bits läßt sich programmieren, in welchen zeit¬ 
lichen Abständen ein periodischer Interrupt ausgelöst werden 
kann. 

Außerdem wird dadurch gleichzeitig die Ausgangsfrequenz 
des Rechtecksignals am SQW-Ausgang (im TT nicht verwen¬ 
det!) eingestellt. 

Betrachtet man die vier Rate-Select-Bits als eine vierstellige 
Binärzahl mit RS3 als höchstwertigem Bit, so berechnen sich 
die Ausgangsfrequenz für den SQW-Ausgang und die Zeit¬ 
abstände zwischen zwei periodischen Interrupts wie folgt. 

Mit RS = 8 x RS3 + 4 x RS2 + 2 x RS1 + RSO ergibt sich: 


32768 Hz 

SQW-Freq. = — — 

2 »s-n 


1 


INT-Zeit = 


SQW-Frequenz 
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Register $0B 

Alle Bits dieses Registers können beschrieben und ihr aktueller Zustand ausgelesen werden. 


Bit 7 

Bit 6 

Bit 5 

Bit 4 

Bit 3 

Bit 2 

Bit 1 

Bit 0 

SET 

PIE 

AIE 

UIE 

SQWE 

DM 

24/12 

DSE 


Bei gelöschtem Bit arbeitet der Uhrenchip in gewohnter Weise 
mit einem Update-Zyklus pro Sekunde. Durch Setzen des Bits 
wird ein evtl. Update-Zyklus unterbrochen oder gar nicht erst 
zugelassen, um in Ruhe eine Initialisierung der Zeit-/Datum- 
Register vornehmen zu können. 

Bei gesetztem Bit werden periodische Interrupts in einem 
zeitlichen Abstand, der durch die RS3..RS0-Bits bestimmt 
wird, ausgelöst Zur Signalisierung, daß ein periodischer Inter¬ 
rupt aufgetreten ist, wird im Register $0C durch ein gesetztes 
PF-Bit angezeigt. 

Die Funktion dieses Bits ist ähnlich dem vorgenannten PIE- 
Bit. Bei gesetztem Bit wird ein Interrupt ausgelöst, wenn die 
aktuelle Zeit die Alarmzeit erreicht (unter Berücksichtigung 
von “Don’t care”-Werten in den Alarmzeitregistem). Die Si¬ 
gnalisierung, daß der Interrupt ein Alarmzeit-Interrupt ist, er¬ 
folgt über ein gesetztes AF-Bit im Register $0C. 

UIE (Update ended Interrupt Enable) 

Freigabebit für den Update-ended Interrupt (Bit gesetzt = 
Interrupt ist freigegeben). Die Interrupt-Service-Routine er¬ 
kennt dann durch ein gesetztes UF-Bit in Register $0C, daß die 
Bedingung “Update beendet” die Quelle dieses Interrupts ist. 

SQWE (Square-Wave-Output Enable) 

Mit gesetztem Bit wird der SQW-Ausgang des Uhrenchips 
freigegeben und liefert ein Rechtecksignal der Frequenz, die 
mit den RS0..RS3-Bits in Register $0A eingestellt ist. Bei 
gelöschtem Bit ist der SQW-Ausgang auf Low. 

DM (Data Mode) Bei gesetztem Bit wird in den Zeit- und Datumsregistem mit 

Binärwerten gearbeitet. Bei gelöschtem Bit erwartet und liefert 


SET 


PIE (Periodic Int. Enable) 


AIE (Alarm Int. Enable) 
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der Uhrenchip die Werte im BCD-Format. Ein zwischenzeit¬ 
licher Moduswechsel verlangtauch immer eine Neu-Initialisie- 
rungdes Uhrenchips, dadieserkeineeigeneUmrechnungsfunk- 
tion besitzt. 

24/12 Wenn das Bit gesetzt ist, wird im 24-Stunden-Modus gearbei¬ 

tet, sonst im 12-Stunden-Modus. Die Anzeige für “Nachmit- 
tagszeit” (PM-Anzeige) erfolgt durch ein gesetztes höchstwerti¬ 
ges Bit in den Stundenregistem. 

DSE (Daylights Savings Enable) 

Hiermit kann der Uhrenchip “angewiesen” werden (durch ein 
gesetztes Bit!), Sommer- und Winterzeit automatisch umzu¬ 
schalten. Wenn diese Funktion eingeschaltet ist, springt die 
Uhrzeit am letzten Aprilsonntag von 01:59:59 auf 03:00:00. 
Entsprechend wird am letzten Sonntag im Oktober von 01:59:59 
auf 01:00:00 gewechselt! 

Register $0C 


Alle Bits dieses Registers sind Statusbits und können nur ausgelesen werden. Nach einem 
Lesezugriff werden die Flags wieder zuriickgesetzt! 


Bit 7 

Bit 6 

Bit 5 

Bit 4 

Bit 3 

Bit 2 

BitI 

BitO 

IRQF 

1 PF 

AF 

UF 

0 

0 

0 

0 


IRQF Int. (Request Flag) Dieses Bit wird gesetzt, sobald einer derffeigegebenen Interrupts 

auftritt. 


PF (Periodic Int. Flag) Abhängig von der Einstellung der RS0..RS3-Bits im Regi¬ 
ster $0A wird in bestimmten zeitlichen Abständen dieses Bit 
gesetzt. Wenn der zugehörige Interrupt freigegeben ist (d.h. 
Bit PIE im Register $0B gesetzt), wird dazu ein Interrupt 
ausgelöst, der durch ein gesetztes IRQF-Bit in diesem Register 
angezeigt wird. 

Ein gesetztes AF-Bit zeigt an, daß die aktuelle Zeit die 
eingestellte Alarmzeit (unter Berücksichtigung von evtl. “Don’t 
care”-Einstellungen in den Alarmzeitregistem!) erreicht hat. 
Wenn das zugehörige AIB-Bit im Register $0B ebenfalls ge- 


AF (Alarm Int. Flag) 
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setzt ist, wird auch ein Interrupt ausgelöst, der dann auch durch 
ein gesetztes IRQF-Bit signalisiert wird. 

UF (Update ended Int. Flag) Nach jedem Update-Zyklus wird dieses Bit gesetzt. Wenn der 

zugehörige Interrupt freigegeben ist (= Bit UIEin Register $0B 
gesetzt), erfolgt ebenfalls ein Interrupt, der zusätzlich über ein 
gesetztes IRQF-Bit angezeigt wird. 

Register $0D 

Nur das Bit 7 dieses Registers ist belegt und dient als Statusbit. Das Register kann nur ausge¬ 
lesen werden. 


Bit 7 

Bit 6 

Bit 5 

Bit 4 

Bit 3 

Bit 2 

Bit 1 

BitO 

VRT 

0 

0 

0 

0 

0 

0 

0 


VRT (Valid RAM and Time) Dieses Bit zeigt die Gültigkeit der Daten im Uhrenchip an. Es 

ist auf Null, wenn der PS-Anschluß auf Low liegt (bei ausgeschal¬ 
tetem TT und kurz nach dem Einschalten der Fall). Der Prozes¬ 
sor kann dieses Bit durch einen Lesezugriff auf dieses Register 
setzen, wenn Datum/Zeit und R AM-Inhalte korrekt initialisiert 
wurden. Durch Testen dieses Bits nach dem Einschalten des 
Systems kann der Prozessor feststellen, ob die Daten noch gül¬ 
tig sind. 


Die Programmierung des TT-Uhrenchips 

Als Beispiel für die Programmierung des Uhrenchips des TT soll das nachfolgende Listing 
dienen. Es handelt sich dabei um disassemblierte Routinen aus dem Original TOS 3.01. Die 
ausgeführten Aktionen sind jeweils kommentiert und zeigen letztlichdas Setzen derZeit-/Da- 
tumswerte im Uhrenchip mit Ausgangswerten im GEMDOS-Zeit-/Datumsformat. 


Folgende Routinen stammen aus dem TOS 3.01 und demonstrieren, wie 
Atari die Initialisierung (das Stellen) des Uhrenchips durchführt 


Parameterübergäbe für RTC-Chip als Long auf dem Stack 
[bei 4(a7)] im GEMDOS-Format! 
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setrtc: 


bsr 

chkrtc 

bcs 

seterr 

move.1 

4(a7) ,d0 

move.b 

#$B, rtc_rnr 

move.b 

#$80,rtc data 

move.b 

#$A, rtc__rnr 

move.b 

#$2A,rtc_data 

move.b 

#$B, rtc_rnr 

move.b 

#$8E,rtc_data 

move.b 

#0,rtc rnr 

BFEXTU 

dO {27:5), dl 

add.b 

dl, dl 

move.b 

dl,rtc data 

move.b 

#2,rtc rnr 

BFEXTU 

d0{21:6),dl 

move.b 

dl,rtc data 

move.b 

#4,rtc rnr 

BFEXTU 

d0{l6:5},dl 

move.b 

dl,rtc_data 

move.b 

#7,rtc rnr 

BFEXTU 

dO{11:5}, dl 

move.b 

dl, rtc_data 

move.b 

#8,rtc rnr 

BFEXTU 

dO {7 :4), dl 

move.b 

dl,rtc_data 

move.b 

#9,rtc_rnr 

BFEXTU 

dO {0:7}, dl 

add.b 

#$A, dl 

move.b 

dl,rtc data 

move. b 

#$B,rtc rnr 

move.b 

rts 

#$E,rtc_data 


; Fehler (-1) in dO zurückliefern! 


; Zugriff auf RTC versuchen 
; RTC vorhanden? 

; Ja! Parameter nach dO holen 
; In Register B SET-Bit auf 1, um 

; Update-cycle zu unterbrechen! 

; In Reg. A auf 32 kHz-Timebase 
; und Period-Int. auf 15,625 ms 
; In B-Reg. SQWE-, DM-, und 
; 24-hour-Bit setzen. 

; Reg. 0 ansteuern 
; Sekunden-Wert (Bits 0..4) aus 
; Parameterdaten verdopp. und 
; in SEKUNDEN-Reg. eintragen 
; Minuten-Wert (Bits 5..10) aus 
; Parameterdaten holen und 
; in MINUTEN-Reg. eintragen. 

; Stunden-Wert (Bits 11.. 15) aus 
; Parameterdaten holen und 
; in STUNDEN-Reg. eintragen. 

; Tagesdatum (Bits 16..20) aus 
; Parameterdaten holen und 
; in TAGESDATUM-Reg. eintragen 

; Monatsdatum eintragen 


; Jahresdatum +10 eintragen 


; RTC ist initialisiert! 


seterr: 


moveq #$FF,dO 
rts 
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; Testroutine für Zugriff auf RTC-I/O-Bereich. Wenn RTC nicht vor- 
; handen ist, wird eine eigene Bus-Error-Routine angesprungen und 
; dort dann das Carry-Flag gesetzt (= keine RTC vorhanden!). 

/ 

chkrtc: 


movea.1 

a7, aO 

; Stackptr. in aO merken 

movea.1 

8, al 

; Buserror-Ptr. nach al 

move.1 

#rtcberr,$00000008 

; Buserror-Ptr. auf Adr. 

; $E02372 setzen 

move.b 

#0, rtcjrnr 

; Zugriff auf Sekundenregister 

move.b 

rtc data,d0 

; Wenn die Routine bis hierhin 

move.1 

al, 8 

; kommt, gibt es auch die RTC! 

andi 

rts 

#$EE,ccr 

; Also Buserror-Ptr. restoren 
; und mit Carry-Clear zurück! 


; Die folgende Routine fängt eine Bus-error-Exception ab, wenn auf 
; den RTC- I/O-Bereich zugegriffen wird, ohne daß eine RTC vorhan- 
; den ist! 

r 

rtcberr: 

movea.l a0,a7 
move.1 al, 8 

ori #l,ccr 

rts 


; Stackptr. restoren 
; Alten Buserror-Ptr. restoren 
; Carry-Bit setzen (= No RTC!) 
; Und raus hier! 
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Kapitel 11: Sonstiges zum TT 


Auf die neuen Komponenten und Hardware-Eigenschaften des TT wurde ja in den vorigen 
Kapiteln bereits eingegangen. Dabei wurden jedoch nur jene Funktionsgruppen behandelt, die 
“anders” als beim “normalen” ST/STE sind. Natürlich finden sich bereits von der ST-Serie 
her bekannte (und beschriebene) Bausteine und Funktionsgruppen ebenfalls im TT wieder. 
Auf diese Funktionsgruppen soll deshalb nicht nochmal in besonderen Kapiteln eingegangen 
werden, sondern diese werden in diesem Kapitel noch kurz angesprochen. Informationen zu 
der prinzipiellen Funktionsweise finden sich in den entsprechenden ST-Hardware-Kapiteln. 


DieACIAs im TT 

sind von der Funktion und Beschaltung her gleich mit denen des ST! So ist die Anbindung der 
MIDI-Schnittstellen und der Tastatur identisch mit der beim MEGA ST. 

Die Tastatur mit ihrem Tastaturprozessor verhält sich genau wie die MEGA ST-Tastatur. So 
kann man ohne Probleme die MEGA ST-Tastatur am TT/MEGA STE betreiben und 
umgekehrt. Auch beim TT existiert keine Reset-Leitung mehr zur Tastatur hin. Die Folge ist 
dann auch hier, daß bei einem Tastatur-”Absturz” ein “echter Hardware-Reset” ausgeführt 
werden muß (Rechner aus- und nach einer kurzen Zeit wieder einschalten!), um die Tastatur 
wieder zur Arbeit zu bewegen. Auch der “Trick”, bei gedrückter Maustaste den Rechner einzu¬ 
schalten, führt (wie gewohnt) zu einem unmöglich konfigurierten Tastaturprozessor, mit dem 
ein Arbeiten nicht möglich ist (siehe auch im ST-Hardware-Teil “Die ACIAs im ST”). 


Der PSG im TT 

AuchimTT/MEGA STE wird der YM 2149(AY-5-8910imMEGA STE)alsSoundchipund 
Parallelport benutzt. Das davon erzeugte Soundsignal wird, wie beim STE erläutert, zu dem 
Soundsignal vom PCM-Soundmodul dazugemischt und läßt sich durch entsprechende 
Programmierung des Volume/Tone-Controllers LMC1992 auch bei Bedarf unterdrücken. 

Was die Portanschlüsse des PSG im TT angeht, werden diese, wie vom ST her bereits bekannt, 
als Daten- und Steuerleitungen für den Parallel-Port (Druckerport) und zum Drive- und Side- 
select für die Floppy-Disk-Laufwerke benutzt. Beim TT sind die Steuersignale zur Floppy- 
Disk-Schnittsteile (Drive- und Side-Select) jedoch nochmal über eine Treiberschaltung ge¬ 
puffert und werden erst freigeschaltet, wenn die Betriebsspannung stabil ist (über ein “Power 
Good”-Signal vom Netzteil!). Die beiden Portleitungen IOA7 und 106 weisen eine neue Funk¬ 
tion auf. 
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Mit 10A7 läßt sich beim TT/MEGA STE umschalten, ob der SCC-Kanal A auf dem LAN- 
Anschluß (Mini-DIN-Buchse an der Seite des Gerätes) oder auf dem SERIAL 2-Anschluß 
(9pol. SubD-Buchse an der Rückseite des Gerätes, wenn keine VME-Buskarte eingesteckt 
ist!) arbeitet. Setzt man mit der XBios-Funktion Ongibit($80) den Port-Anschluß IOA7 auf 
“Ein”, ist SERIAL 2 eingeschaltet. Mit Offgibit($7F) arbeitet der SCC-Kanal A auf dem 
LAN-Anschluß. 

Nach neuesten Informationen wird ATARI aber diesen Port-Anschluß des PSG nicht mehr für 
diese Umschaltung verwenden, sondern statt dessen am Parallelport zusätzlich zur Verfügung 
stellen, um das Anschließen von Scannern zu erleichtern. Die Umschaltung der beiden seriel¬ 
len Anschlüsse LAN und SERIAL 2 erfolgt dann über einen Jumper auf der Hauptplatine unter 
der Festplatte. 

IO AG des PSG wird zum Ein- und Ausschalten des Lautsprechers im TT verwendet. Dabei wird 
das Soundsignal vom Volume/Tone-Controller LMC1992, das über eine Treiberstufe auf den 
Lautsprecher gelangt, durch ein Low am IOA6-Anschluß eingeschaltet. 

Ongibit($40): Lautsprecher im TT stummschalten. 

Offgibit($BF): Lautsprecher im TT einschalten. 

Wichtig! Das Ein- und Ausschalten über IO A6 des PSG betrifft nur den internen Lautsprecher 
und nicht das über die Cinch-Buchsen (Audio out Links und Rechts) abgreifbare Tonsignal! 


DMA-Sound im TT 

Die Erzeugung und Kontrolle des PCM-Stereo-Sounds funktioniert im TT/MEGA STE 
genauso, wie beim STE beschrieben! Also können alle Adressen und Funktionsbeschreibungen 
(auch was das MMICROWIRE !TM) -Intcrface angeht!) dazu direkt im Hardware-Teil “Die 
Hardware des ATARI STE” nachgelesen werden. 

Auch was die Verknüpfung vom “Monochrom-Detecf’-Signal mit dem Frame-Ende-Signal 
an Port 17 des MFP (im TT ist das der ST-MFP!) angeht, ist alles so, wie beim STE beschrieben. 
Man muß nur beachten, daß mit Monochrombetriebsart beim TT eben die TT-High-Auflö¬ 
sung gemeint ist und nicht etwa ST-High! 

Die etwas geänderte Schaltung (andere Unit-Nummern und zusätzliche Lautsprechertreiber- 
Stufe) für den TT ist nachfolgend aufgefühlt! 

Weil im TT kein SHIFTER der STE-Serie zum Einsatz kommt, mußte der DMA-Soundbetrieb 
über einen eigenen SOUNDSHIFTER realisiert werden. Dieser Custom-Chip dient zur 
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Abb. 11.1: Der TT-DMA-Soundteil 


Erzeugung der Sound-DMA- und für die MICROWIRE (TM) -Steuersignale. Für den Program¬ 
mierer verhält sich dieser Chip aber genauso wie der Sound-DMA-Teil des STE-SHDFTERS! 
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Das Floppy-Disk Interface 

Was die Ansteuerung der Floppy-Disk-Laufwerke im TT/MEGA STE angeht, funktioniert 
(erstmal) alles genauso, wie bereits beim ST beschrieben. 

Weil aber 720 KByte auf einer 3,5"-Disk wohl nicht mehr so ganz zeitgemäß sind, hat ATARI 
auf Abhilfe gesonnen und eine Möglichkeit vorgesehen, die Speicherkapazität zu verdoppeln. 
Diese erhöhte Kapazität erfordert spezielle Disketten (HD-Disks) und natürlich auch entspre¬ 
chende HD-Disklaufwerke. 

Um die doppelte Speicherkapazität zu erhalten, werden pro Spur bei HD-Betrieb nun die dop¬ 
pelte Anzahl an Sektoren pro Spur untergebracht. Das geht nur mit einer höheren Datentrans¬ 
ferrate auf den Schreib- und Lesedatenleitungen zum Laufwerk. Um diese Verdopplung der 
Datenrate zu erzielen, wird bei HD-Betrieb der Systemtakt des FDC-Chips verdoppelt (statt 
8 MHz dann 16 MHz!). Den Arbeitstakt für den FDC liefert im TT die MCU (U206) an 
Pin 44, die auch die Taktumschaltung vomimmt. 


TT und MEGA STE sind (im Prinzip) HD-tähig 

Die Verdopplung des Taktes “verkraften” aber nicht alle Exemplare des WD1772-FDC-Chips 
(schließlich ist dieser ja auch nur für 8 MHz ausgelegt!). ATARI will aber einen “eigenen”, 
zum WD1772 aufwärtskompatiblen FDC-Chip liefern, der diese Taktumschaltung be¬ 
herrscht. In meinem TT arbeitet allerdings auch bereits der “gute, alte WD1772” mit 16 MHz 
einwandfrei und bedient ein nachträglich eingebautes HD-Laufwerk! Allerdings gibt es bei 
Dauerbetrieb mit dieser hohen Taktfrequenz Probleme mit der Wärmeentwicklung des FDC! 
Zwar “stirbt” dieser nicht gerade, aber er arbeitet nicht mehr sicher. 

Die Umschaltung des internen Laufwerks auf HD erfolgt über ein High-Signal an Pin 2 des 
Floppy-Steckverbinders. Dieser Anschluß existiert aber an der Anschlußbuchse zum externen 
Laufwerk nicht! Wenn man also mit einem externen, HD-fahigen Laufwerk arbeiten will, 
sollte dieses so konfiguriert werden, daß es die HD-Betriebsart aus der zusätzlichen Öffnung 
einer HD-Diskette erkennt und entsprechend umschaltet. Das TOS erkennt HD-formatierte 
Disks durch entsprechende Leseversuche mit den beiden möglichen Taktfrequenzen für den 
FDC. 

Welche Density ein korrektes Lesen ermöglicht, wird im Drive-Status-Block gemerkt, der für 
diese Information erweitert wurde. Im TOS 3.01 findet sich der Drive-Status-Block (DSB) für 
das Laufwerk A (“dsbO”) an Adresse $AFA. Der zweite DSB (“dsbl”) liegt bei $B00! Vor¬ 
sicht! Das sind Adressen von internen Datenstrukturen, die sich von TOS-Version zu TOS- 
Version ändern können! Also erst gar nicht benutzen! Für das Formatieren sollten die ent- 
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sprechenden Betriebssystem-Funktionen benutzt werden. Die behandeln die angeschlossene 
Hardware dann schon richtig! 

Jeweils das zweite Word eines DSB wird für die aktuelle Density-Einstellung benutzt. Dabei 
ist das niedrigwertigste Bit für die Takteinstellung (Bit 0 = 1: 16 MHz-Takt) und das Bit 1 
für die Density-Signalisierung (Pin 2 des Floppy-Steckverbinders) zum Laufwerk zuständig 
(Bit 1 = 1: Density-Leitung auf High!). 



Abb. 11.2: DerTT/MEGA STE ACS1-Busanschluß 
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Das Hardware-Register (Word-Zugriffe, nur die beiden untersten Bits werden verwendet) für 
die Taktumschaltung und die Ansteuerung der HD-Signal-Leitung liegt bei Adresse 
$(FF)FF 860E! Auch diese Adresse ist nicht von ATARI dokumentiert und kann sich evtl, 
ändern. Also nicht direkt verwenden! 


Der TT/MEGA STE und der ACSI-Bus 

Auch hier gibt’s gegenüber der Ausführung im ST keine gravierenden Änderungen. Die 
wesentlichste Abweichung besteht in der Verwendung von Treiberstufen für die ACSI-Bus- 
Signale zur S tabilisierung der Signale. Außerdem wird der DMA-Chip dadurch etwas weniger 
anfällig gegen Zerstörungen von “Außen”. 

Beim MEGA STE hat ATARI ja ebenfalls eine Festplatte (SCSI!) mit ins Gehäuse eingebaut. 
Für deren Betrieb ist dann natürlich ein entsprechender Hostadapter erforderlich, um die AC- 
SI-Bussignale auf SCSI-Signale umzusetzen. Der Anschluß dieses Hostadapters erfolgt über 
eine 30pol. Pfostenfeldleiste auf dem Motherboard des MEGA STE. Die Datenbusleitungen 
werden dabei “durch” den Hostadapter geführt (eine Seite Input; andere Seite Output)! Wenn 
kein Hostadapter eingebaut ist, müssen deshalb die Datenbusleitungen an der Pfostenfeldleiste 
gebrückt sein, um die Signale auch am außenliegenden ACSI-Anschluß zur Verfügung zu ha¬ 
ben ! Die interne Platte hat standardmäßig die ACSI-Device-Nummer 0. Außen angeschlosse¬ 
ne ACSI-Device sollten sich also daran entsprechend anschließen. 



Anhänge 
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Anhang A: BIOS-, XBIOS- und 
GEMDOS-Fehlermimmern 

TOS-Fehlermeldungen 

Beim Aufruf von BIOS-, XBIOS- und GEMDOS-Funktionen wird im allgemeinen im 
Register DO ein 32-Bit-Statuswert zurückgeliefert, der darüber Auskunft gibt, ob, und wenn 
ja, was für ein Fehler bei der Ausführung der Funktion aufgetreten ist. Hier eine Übersicht: 

0: E_OK (“OK (no error)”) 

Funktion erfolgreich ausgeführt (kein Fehler aufgetreten). 

-1: ERROR (“Error”) 

Es ist ein Fehler aufgetreten, der nicht genauer spezifiziert werden kann. 

-2: EDRVNR (“Drive not ready”) 

Angesprochenes Gerät ist nicht angeschlossen, nicht funktionsbereit oder reagiert nicht 
innerhalb der gesetzten Frist (Timeout). 

-3: EUNCMD (“Unknown command”) 

Dem angesprochenen Peripheriegerät ist das gegebene Kommando unbekannt. 

-4: E CRC (“CRC error”) 

Beim Lesen eines Sektors ist ein Fehler aufgetreten (aufgetreten bei der CRC-Überprüfung). 
-5: EBADRQ (“Bad request”) 

Das Peripheriegerät kann das Kommando nicht ausführen. Befehlsparameter und Kontext 
prüfen. 

- 6 : E_SEEK (“Seek error”) 

Der angesprochene Track konnte vom Laufwerk nicht erreicht werden. 
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-7: EMEDIA (“Unknown media”) 

Leseversuch gescheitert, da das Medium keinen korrekten Bootsektor besitzt. 

-8: ESECNF (“Sector not found”) 

Der betreffende Sektor wurde nicht gefunden. 

-9: EPAPER (“Out of paper”) 

Drucker nicht betriebsbereit. 

-10: EWRITF (“Write fault”) 

Fehler bei Schreiboperation aufgetreten. 

-11: EREADF (“Read fault”) 

Fehler bei Leseoperation aufgetreten. 

-12: EGENRL (“General error”) 

Allgemeiner Fehler (Kommentar im “Hitchhiker’s guide to the Bios”: ‘Reserved for future 
catastrophes’). 

-13: EWRPRO (“Write on write-protected media”) 

Es wurde versucht, auf ein schreibgeschütztes Medium zu schreiben. 

-14: ECHNG (“Media change detected”) 

Seit der letzten Schreiboperation wurde das Medium gewechselt. 

-15: EUNDEV (“Unknown device”) 

Das angesprochene Gerät ist dem Betriebssystem unbekannt. 

-16: EBADSF (“Bad sectors on formaf’) 

Beim Formatiervorgang wurden defekte Sektoren entdeckt. 
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-17: EOTHER (“Insert other disk (request)”) 

Eine andere Diskette muß eingelegt werden. Tritt nur auf, wenn Laufwerk B: angesprochen 
wird, ohne angeschlossen zu sein. 

In diesem Fall wird der Benutzer aufgefordert, “Diskette Bin das erste Laufwerk einzulegen. 

-18: EINSERT (“Insert disk”) 

Meta-DOS-Fehler: Medium einlegen! 

-19: EDVNRSP (“Device not responding”) 

Meta-DOS-Fehler: Gerät antwortet nicht. 

-32: EINVFN (“Invalid function number”) 

Unbekannte Funktionsnummer. Man erhält diese Meldung, wenn man eine Undefinierte 
GEMDOS-Funktion aufruft (unter MS-DOS: Fehlercode 1). 

-33: EFILNF (“File not found”) 

Datei nicht gefunden (unter MS-DOS: Fehlercode 2). 

-34: EPTHNF (“Path not found”) 

Angesprochener Ordner nicht gefunden (unter MS-DOS: Fehlercode 3). 

-35: ENHNDL (“Handle pool exhausted”) 

Keine Dateihandles mehr (zu viele Dateien geöffnet, unter MS-DOS: Fehlercode 4). 

-36: EACCDN (“Access denied”) 

Zugriff nicht erlaubt (unter MS-DOS: Fehlercode 5). 

-37: EIHNDL (“Invalid handle”) 

Das Dateihandle war nicht korrekt (unter MS-DOS: Fehlercode 6). 

-39: ENSMEM (“Insufficient memory”) 

Nicht genügend Speicher vorhanden (unter MS-DOS: Fehlercode 8). 
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-40: EIMBA (“Invalid memory block address”) 

Die Adresse des Speicherblocks war nicht gültig (unter MS-DOS: Fehlercode 9). 

-46: EDRIVE (“Invalid drive specification”) 

Die Laufwerksbezeichnung war ungültig (unter MS-DOS: Fehlercode 15). 

-48: ENSAME (“Notthe same drive”) 

Dateien sind auf verschiedenen logischen Laufwerken. 

-49: ENMFIL (“No more flies”) 

Es können keine Dateien mehr geöffnet werden (unter MS-DOS: Fehlercode 18). 

-58: ELOCKED (“Record is locked”) 

Es wurde versucht, auf einen gelockten Bereich einer Datei zuzugreifen (nur im Zusammen¬ 
hang mit einer Netzwerk-GEMDOS-Version). 

-59: ENSLOCK (“Matching lock not found”) 

Es wurde versucht, einen nicht existierenden Lock (falscher Offset oder/und falsche Länge) 
zu entfernen (nur im Zusammenhang mit einer Netzwerk-GEMDOS-Version). 

-64: ERANGE (“Range error”) 

Dateizeiger in ungültigem Bereich. 

-65: EINTRN (“GEMDOS internal error”) 

Interner Fehler im GEMDOS (hoffentlich passiert’s nie!). 

-66: EPLFMT (“Invalid executable file formaf’) 

Das angesprochene Programm hat nicht das korrekte Format, um geladen zu werden. 

-67: EGSBF (“Memory block growth failure”) 

Es wurde versucht, einen allozierten Speicherblock zu vergrößern. 



Anhang B: 

Wichtige Betriebssystemstrukturen 
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AESPB (AES Parameter Block) 


Offset 

Struktur 


typedef struct 
{ 

WORD *cb pcontrol; 

$00 

$04 

WORD *cb pglobal; 

$08 

WORD *c.b_pintin; 

$0C 

WORD *cb_pintout; 

$10 

LONG *cb_padrin; 

$14 

LONG *cb_padrout; 

} AESPB; 


/* Zeiger auf 
/* Zeiger auf 
/* Zeiger auf 
/* Zeiger auf 
/* Zeiger auf 
/* Zeiger auf 


contrl[] V 
global[] */ 
int__in[] */ 
int_out[] */ 
addr_in[] */ 
addr out[] */ 


ARHEADER (Archivheader) 


Offset 

Struktur 



typedef struct 
{ 

char a_fname[14]; 


$00 

/* 

$0E 

LONG a_modti; 

/* 

$12 

BYTE a userid; 

/* 

$13 

BYTE a__gid; 

/* 

$14 

WORD a_fimode; 

/* 

$16 

LONG a__fsize; 

/* 

$1A 

WORD reserved; 

} ARHEADER; 

/* 


Dateiname */ 

Zeitpunkt des letzten Zugriffs */ 
nicht benutzt */ 
nicht benutzt */ 

Filemodus */ 

Dateilänge */ 

Null */ 
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BASEPAGE 


Offset 

Struktur 


$00 

typedef struct basepage 
{ 

void *p lowtpa; /* Anfangsadresse der TPA (Offset 0) */ 

$04 

void *pjnitpa; 

/* Erstes Byte nach dem Ende der TPA 

$08 

void *p tbase; 

(Offset 4) */ 

/* Anfangsadresse des Programmcodes 

$0C 

LONG p_tlen; 

(TEXT-Abschnitt) (Offset 8) */ 

/* Länge des Programmcodes 

$10 

void *p dbase; 

(Offset 12) */ 

/* Adresse des Bereichs für vorinitia¬ 

$14 

LONG p dien; 

lisierte Daten (DATA-Abschnitt) 
(Offset 16) */ 

/* Länge des Datenabschnitts 

$18 

void *p bbase; 

(Offset 20) */ 

/* Adresse des Variablenbereichs (BSS- 

$1C 

LONG p_blen; 

Äbschnitt) (Offset 24) */ 

/* Länge des Variablenbereichs 

$20 

DTA *p dta; 

(Offset 28) */ 

/* Zeiger auf Default-DTA (Vorsicht! 

$24 

struct basepage 

Zeigt zunächst in die Kommandozeile) 
(Offset 32) */ 

*p_parent ; 

$28 

LONG p resrvdO; 

/* Zeigt auf die Basepage (BASEPAGE)' 
des aufrufenden Prozesses 
(Offset 36) */ 

/* reserviert */ 

$2C 

char *p env; 

/* Adresse der Environment-Strings 

$30 

(Offset 44) */ 

CHAR p_resrvdl[80] ; /* reserviert */ 

$80 

char p_cmdlin[128]; /* Kommandozeile (dabei wird im er- 


sten Byte die Anzahl der Zeichen 
eingesetzt. Die maximale Lange der 
Kommandozeile beläuft sich 
erstaunlicherweise nicht auf 127, 
sondern auf 124 Zeichen.) 

(Offset 128) */ 

} BASEPAGE; 
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BCB (Buffer Control Block) 


Offset 

Struktur 


typedef struct 

1 t 

struct __bcb 

_bcb 


$00 

*b_link; 

/* 

$04 

WORD 

b negl; 

/* • 

$06 

WORD 

bjprivate [5]; 

$10 

void 

*b_buf; 

/* : 


} BCB; 




Zeiger 
auf -1 

Zeiger 

Puffer 


auf nächsten BCB */ 
initialisieren */ 

auf den eigentlichen 
*/ 


BCONMAP (siehe ‘BconmapO’) 


Offset 

Struktur 


typedef struct 
{ 

MAPTAB *maptab; 

WORD maptabsize; 

} BCONMAP; 


$00 

$04 

/* Zeiger auf Funktionstabelle */ 
/* Anzahl der Einträge */ 


BITBLK 


Offset 

Struktur 


typedef struct 
/ 


$00 

UWORD 

*bi_pdata; 

/* Zeiger auf Image */ 

$04 

DWORD 

bi__wb; 

/* Breite in Bytes *1 

$06 1 

DWORD 

bi_hl; 

/* Höhe in Pixelzeilen */ 

$08 

WORD 

bi_x; 

/* X~Position */ 

$0A 

WORD 

bi_y; 

/* Y-Position */ 

$0C 

WORD 

bi__color; 

/* Farbe */ 


} BITBLK; 
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BPB (BIOS Parameter Block) 


Offset 


Struktur 


typedef struct 


{ 


$00 

$02 

$04 

$06 


WORD recsiz; 
WORD clsiz; 
WORD clsizb; 
WORD rdlen; 


/* Bytes pro Sektor */ 

/* Sektoren pro Cluster {Einheit) */ 
/* Bytes pro Cluster */ 

/* Länge des Wurzelverzeichnisses in 
Sektoren */ 


$08 

$0A 

$0C 


WORD fsiz; /* Länge des File Allocation Table (FAT) 
WORD fatrec; /* Startsektor der zweiten FAT */ 

WORD datrec; /* Sektornummer des ersten freien 

Clusters */ 


*/ 


$0E 

$10 


WORD numcl; /* Cluster-Gesamtzahl auf dem Medium */ 
WORD bflags; /* Bitvektor, zur Zeit nur Bit 0 belegt: 

0 (12-Bit-FAT), 1 (16-Bit-FAT) */ 


} BPB; 


CPXHEAD (CPX-Dateikopf) 


Offset 

Struktur 

$00 

typedef struct 
{ 

UWORD magic; 

$02 

struct 

{ 

unsigned reserved 
unsigned resident 
unsigned bootinit 
unsigned setonly 
} flags; 

LONG cpx id; 

$04 

$08 

UWORD cpx version; 

$0A 

char i text[14); 

$18 

UWORD sm_icon [48]; 

$78 

□WORD i color; 


/* = 100 */ 


13; /* reserviert */ 

1; /* RÄM-resident */ 

1; /* Boot-Initialisierung */ 

1; /* Set-Only */ 

/* eindeutige CPX-ID */ 

/* CPX-Versionsnummer */ 

/* Icontext */ 

/* Bitmap {32x24 Pixel) */ 
/* Iconfarbe */ 
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Offset 

Struktur 

$7A 

char 

title text[18]; 

$7C 

UWORD 

t__color; 

$8E 

char 

buffer[64]; 

$CE 

char 

reserved[306]; 


} CPXHEAD 



/* Name */ 

/* Textfärbe */ 

/* nicht flüchtiger Puffer */ 
/* reserviert */ 


CPXINFO 


Offset 

Struktur 


typedef struct 
s 

$00 

X 

WORD cdecl 

$04 

void cdecl 

$08 

void cdecl 

$0C 

void cdecl 

$10 

void cdecl 

$14 

void cdecl 

$18 

void cdecl 

$1C 

void cdecl 

$20 

WORD cdecl 

$24 

void cdecl 


} CPXINFO; 


(*cpx_call)(GRECT *work); 

(*cpx__draw) (GRECT *clip) ; 

(*cpx_wmove)(GRECT *work); 

(*cpx_timer)(WORD *event); 

(*cpx_key)(WORD kstate, WORD key, 

WORD *event); 

(*cpx_button)(MRETS *mrets, WORD *event); 
(*cpx_ml)(MRETS *mrets, WORD *event); 
(*cpx_m2)(MRETS *mrets, WORD *event); 
(*cpx_hook)(WORD event, WORD *msg, 

MRETS *mrets, WORD *key, WORD *nclicks); 
(*cpx_close)(WORD flag); 


DIR (Verzeichnis-Eintrag) 


Offset 


Struktur 


typedef struct 


$00 

$0B 


{ 

char dirjname[11]; 

BYTE dir attr; 


/* Name inkl. Erweiterung ohne 
Punkt */ 

/* Attribut */ 



1228 


ATARI Profibuch 


Offset 

Struktur 

$0C 

BYTE 

dir dummy[10]; 

/* 

unbenutzt */ 

$16 

UWORD 

dir_time; 

/* 

Erstellungszeit */ 

$18 

UWORD 

dir date; 

/* 

Erstellungsdatum */ 

$1A 

UWORD 

dir stcl; 

/* 

erster Cluster */ 

$1C 

ULONG 

dir_flen; 

/* 

Länge der Datei */ 


} DIR; 





DISKINFO 


Offset 

Struktur 


typedef struct 
{ 

LONG b free; 



$00 

/* 

Anzahl der freien Cluster */ 

$04 

LONG b_total; 

/* 

Gesamtzahl der Cluster */ 

$08 

LONG b_secsiz; 

/* 

Bytes pro Sektor */ 

$0C 

LONG b clsiz; 

/* 

Sektoren pro Cluster /* 


} DISKINFO; 



DOSTIME 



Offset 

Struktur 




typedef struct 
{ 

UWORD time; 



$00 

/* 

Zeit wie in "Tgettime" */ 

$02 

UWORD date; 

} DOSTIME; 

/* 

Datum wie in "Tgetdate" */ 


DTA (Disk Transfer Area) 


Offset 

Struktur 


typedef struct 
( 

BYTE d_reserved[21]; 


$00 

/* fürs GEMDOS reserviert */ 



Angang B: Wichtige Betriebssystemstrukturen 


1229 


Offset 


$15 

$16 

$18 

$1A 

$1E 


FONT 

Offset 


$00 

$02 

$04 

$24 


$26 

$28 

$2A 

$2C 

$2E 

$30 

$32 

UWORD 

$36 

$38 

$3A 


Struktur 


BYTE d_attrib; 

/* 

Datei-Attribut */ 

UWORD d_t irrte; 

/* 

Uhrzeit */ 

UWORD d_date; 

/* 

Datum */ 

LONG d_length; 

/* 

Dateilänge */ 

char d_fname[14]; 

/* 

Dateiname */ 

} DTA; 




HDR 

Struktur 


typedef struct 

{ 

WORD 


WORD 

char 

UWORD 


font_id; 
point; 
name[32]; 
first ade; 


UWORD 

last_ade; 


UWORD 

top; 

/* 

UWORD 

ascent; 

/* 

UWORD 

half; 

/* 

UWORD 

descent; 

/* 

UWORD 

bottom; 

/* 

UWORD 

max_char_width; 

/* 

max cell_ 

width; 

/* 

UWORD 

left_offset 

r 

UWORD 

right offset; 

UWORD 

thicken; 



/* Fontnurnmer */ 

/* Größe im Punktmaß */ 

/* Name des Zeichensatzes */ 

/* Erstes Zeichen im Zeichensatz 
(nur die wenigsten Drucker- 
Schriften enthalten Control- 
Zeichen, also ASCII-Werte 
kleiner 32) */ 

/* Letztes Zeichen im 
Zeichensatz */ 

Abstand Topline<->Baseline */ 
Abstand Ascentline<->Baseline */ 
Abstand Halfline<->Baseline */ 
Abstand Descentline<->Baseline*/ 
Abstand Bottomline<~>Baseline */ 

größte Zeichenbreite */$34 

größte Zeichenzellenbreite */ 

/* linker Offset für 
Kursivschrift */ 

/* rechter Offset für 
Kursivschrift */ 

/* Verbreiterungsfaktor für 
Fettschrift (bei Fettschrift 
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Offset Struktur 

wird die Breite um genau so 
viele Pixel erhöht) */ 

$3C UWORD ul_size; /* Dicke der Unterstreichung */ 

$3E UWORD lighten; /* Maske für helle Schrift (wird 

mit Raster undiert, normaler¬ 
weise 0x5555) */ 

$40 UWORD skew; /* Maske für Kursivschrift (be¬ 

schreibt, an welchen Stellen 
die Rasterzeilen verschoben 
werden sollen, normalerweise 
0x5555 */ 

$42 UWORD flags; /* Bit 0: gesetzt, wenn es der 

"Default System font" ist 
Bit 1: gesetzt, wenn die 
"Horizontal offset table" 
benutzt wird 

Bit 2: gesetzt, wenn Bytes 
nicht vertauscht werden müs¬ 
sen (Motorola-Format) 

Bit 3: gesetzt, wenn der Font 
nicht proportional ist */ 

$44 BYTE *hor_table; /* Zeiger auf "horizontal offset 

table"; in der Datei der 
Offset zum Dateibeginn */ 

$48 UWORD *off_table; /* Zeiger auf "character offset 

table" */ 

$4C UWORD *dat_table; /* Zeiger auf Fontimage */ 

$50 UWORD form_width; /* Breite des Zeichensatzimage*/ 

$54 UWORD form_height; /* Höhe des Zeichensatzimage */ 

$58 FONT_HDR *next_font; /* Zeiger auf nächsten Font¬ 

header (in der Fontdatei 
zunächst unbenutzt) */ 

} FONT HDR; 
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GEM_MUPB (GEM Memory Usage Parameter Block) 

Offset Struktur 

typedef struct 

{ 

$00 LONG gmjmagic; 

$04 void *gm_end; 

$08 void *gm_init; 

} GEM MUPB; 


GRECT 

Offset Struktur 

typedef struct 

{ 

$00 WORD g_x; /* X-Position */ 

$02 WORD g_y; /* Y-Position */ 

$04 WORD g_w; /* Breite */ 

$06 WORD g_h; /* Höhe */ 

} GRECT; 


ICONBLK 

Offset Struktur 

typedef struct 

{ 

$00 UWORD *ib_pmask; 

$04 UWORD *ib_pdata; 

$08 char *ib_ptext; 

$0C UWORD ib char; 


/* Zeiger auf Icon-Maske */ 

/* Zeiger auf Icon-Daten */ 

/* Zeiger auf Icon-Text */ 

/* Zeichen, das im Icon erschei¬ 
nen soll, und Vorder- und 
Hintergrundfarbe des Icons */ 


/* muß 0x87654321 sein */ 

/* Ende des von GEM benötigten 
Speicherbereichs */ 

/* Startadresse von GEM */ 
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Offset 

Struktur 

$0E 

UWORD 

ib xchar; 

/* 

dessen X-Position */ 


$10 

DWORD 

ib_ychar; 

/* 

dessen Y-Position */ 


$12 

DWORD 

ib xicon; 

/* 

X-Position des Icons */ 


$14 

UWORD 

ib_yicon; 

/* 

Y-Position des Icons */ 


$16 

UWORD 

ib wicon; 

/* 

Breite des Icons */ 


$18 

UWORD 

ib hicon; 

/* 

Höhe des Icons */ 


$1A 

WORD 

ib_xtext ; 

/* 

X-Position der Beschriftung 

*/ 

$1C 

WORD 

ib_ytext; 

/* 

Y-Position der Beschriftung 

*/ 

$1E 

UWORD 

ib wtext; 

/* 

Textbreite in Pixel */ 


$20 

UWORD 

ib_htext; 

/* 

Texthöhe in Pixel */ 


$22 

UWORD 

ib resvd; 

/* 

reserviert */ 



} ICONBLK, 






IMGHEADER 


Offset 

Struktur 


$00 

typedef struct 
{ 

I WORD im Version; /' 

$02 

DWORD 

im_headlength; 

$04 

UWORD 

im nplanes; 

$06 

UWORD 

im patlen; 

$08 

UWORD 

im_pixwidth; 

$QA 

UWORD 

im^pix height; 

$0C 

UWORD 

im_scanwidth; 

$0E 

UWORD 

im nlines; 


} IMGHEADER; 


Versionsnummer der Imagedatei*/ 
/* Länge des Headers in Words */ 
/* Anzahl der Farbebenen */ 

/* Musterlänge in Byte */ 

/* Pixelbreite in mm/1000 */ 

/* Pixelhöhe in mm/1000 */ 

/* Zeilenbreite in Pixel */ 

/* Anzahl der Zeilen */ 


IOREC 


Offset 

Struktur 


typedef struct 
{ 

LONG ibuf; /* 

WORD ibufsiz; /* 


$00 

$04 

Zeiger auf den Puffer */ 

Länge des Puffers */ 
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Offset 

Struktur 



$06 

WORD ibufhd; 

/* 

nächste Schreibposition */ 

$08 

WORD ibuftl; 

/* 

nächste Leseposition */ 

$0A 

WORD ibuflow; 

/* 

"untere Wassermarke" */ 

$0C 

WORD ibufhi; 

/* 

"obere Wassermarke" */ 


} IOREC; 



LINEA 




Offset 

Struktur 




typedef struct 

{ 

$00 WORD PLANES; /* Anzahl der Bildschirmebenen (+$00) */ 

$02 WORD WIDTH; /* Bytes pro Bildschirmzeile (+$02) */ 

$04 LONG CONTRL; /* Zeiger auf contrl[] (VDI) (+$04) */ 

$08 LONG INTIN; /* Zeiger auf int_in[] (VDI) (+$08) */ 

$0C LONG PTSIN; /* Zeiger auf pts_in[] (VDI) (+$0C) */ 

$10 LONG INTOUT; /* Zeiger auf int_out[] (VDI) (+$10) */ 

$14 LONG PTSOUT; /* Zeiger auf pts_out[] (VDI) (+$14) */ 

$18 WORD COLBITO; /* Farbwert für Plane 0 (+$18) */ 

$1A WORD COLBIT1; /* Farbwert für Plane 1 (+$1A) */ 

$1C WORD COLBIT2; /* Farbwert für Plane 2 (+$1C) */ 

$1E WORD COLBIT3; /* Farbwert für Plane 3 (+$1E) */ 

$20 WORD LSTLIN; /* letzten Pixel einer Linie zeichnen (1) 

oder nicht zeichnen (0) +$20) */ 

$22 WORD LNMASK; /* Muster für Linien (+$22) */ 

$24 WORD WMODE; /* VDI-Schreibmodus (+$24) */ 

$26 WORD XI,Y1,X2,Y2; 

/* Koordinatenangaben (+$26) */ 

$2E LONG PATPTR; /* Zeiger auf Füllrauster (+$2E) */ 

$32 WORD PATMSK; /* dazugehörige Maske (+$32) */ 

$34 WORD MFILL; /* Füllmuster monochr./farbig (+$34)*/ 

$36 WORD CLIP; /* Clipping aus/an (+$36) */ 

$38 WORD XMINCL, YMINCL; 

/* linke obere Ecke d. Clip-rect. (+$38)*/ 
$3C WORD XMAXCL, YMAXCL; 

/* rechte untere Ecke des Clip-rect. 

(+$3C) */ 
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Offset Struktur 

$40 WORD XDDA; /* vor Textausgaben auf 0x8000 setzen 

(+$40) */ 

$42 WORD DDAINC; /* Vergrößerungsfaktor - bei Vergrößerung: 

256*(Wunschgröße-Aktuelle)/Aktuelle; 
bei Verkleinerung: 

256*(Wunschgröße)/Aktuelle (+$42) */ 

$44 WORD SCÄLDIR; /* Vergrößerungsrichtung (0: verkleinern, 

1: vergrößern) (+$44) */ 

$46 WORD MONO; /* Proportionalschrift ja/nein (+$46) */ 

$48 WORD SOURCEX,SOURCEY; 

/* X,Y-Koordinate im Zeichensatz (+$48) */ 
$4C WORD DESTX,DESTY; 

/* Koordinate des Zeichens auf dem Bild¬ 

schirm (+$4C) */ 

$50 WORD DELX,DELY; /* Breite und Höhe des Zeichens (+$50) */ 

$54 FONT_HDR *FBASE; 

/* Zeiger auf Zeichensatzimage (+$54) */ 

$58 WORD FWIDTH; /* Breite des Zeichensatzimage (+$58) */ 

$5A WORD STYLE; /* Schreibstil (+$5A) 

Bit 0: Fettschrift 

Bit 1: Helle Schrift 

Bit 2: Kursivschrift 

Bit 3: Unterstrichene Schrift 

Bit 4: Umriß-Schrift */ 

$5C WORD LITEMASK; /* Maske für das Schattieren (light) 

(+$5C) */ 

$5E WORD SKEWMASK; /* Maske für Italics (+$5E) */ 

$60 WORD WEIGHT; /* zusätzliche Breite bei Bold (+$60) */ 

$62 WORD ROFF; /* Kursiv-Offset rechts (+$62) */ 

$64 WORD LOFF; /* Kursiv-Offset links (+$64) */ 

$66 WORD SCALE; /* Vergrößerung ja/nein (+$66) */ 

$68 WORD CHUP; /* Rotationswinkel * 10 (+$68) */ 

$6A WORD TEXTFG; /* Textfarbe (+$6A) */ 

$6C LONG SCRTCHP; /* Zeiger auf temp. Buffer für Texteffekte 

(+$6C) */ 

$70 WORD SCRPT2; /* Offset für denselben (+$70) */ 

$72 WORD TEXTBG; /* Texthintergrundfarbe (+$72) */ 

$74 WORD COPYTRAN; /* Flag für 'COPY RASTER FORM' 

(0: "opaque", 1: "transparent") (+$74) */ 




Angang B: Wichtige Betriebssystemstrukturen 


1235 


Offset 

Struktur 


$76 

LONG SEEDABORT; 

} LINEA; 

/* Pointer auf Routine, die nach jeder 
Bildzeile eines "SEEDFILL" auf¬ 
gerufen wird (+$76) */ 


KBDVECS 


Offset 

Struktur 


typedef struct 

i 

$00 

t 

void (*mid±vec)(); 

$04 

void (*vkbderr)(); 

$08 

void (*vmiderr) {) ; 

$0C 

void (*statvec)(); 

$10 

void (*mousevec)(); 

$14 

void (*clockvec)(); 

$18 

void (*joyvec)(); 

$1C 

void (*midisys) () ; 

$20 

void (*ikbdsys)0; 

$24 

WORD drvstat; 


} KBDVECS; 


/* Midi-Eingabe */ 

/* Tastatur-Fehler */ 

/* MIDI-Fehler */ 

/* Status von IKBD lesen */ 
/* Mausabfrage */ 

/* Uhrzeitabfrage */ 

/* Joystickabfrage */ 

/* MIDI-Systemvektor */ 

/* IKBD-Systemvektor */ 

/* IKBD-Treiberstatus */ 


KEYTAB 


Offset 


Struktur 


typedef struct 


$00 

$04 


{ 

char *unshift; 
char *shift; 


$08 


char *capslock; 
} KEYTAB; 


/* Tabelle für "normale" Tastendrücke */ 
/* Tabelle für Tastendrücke mit 
"Shift" */ 

/* Tabelle für Tastendrücke bei 
"Capslock" */ 
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MAPTAB (siehe ‘BconmapO’) 


Offset 

Struktur 


typedef 

{ 

WORD 

struct 



$00 

(*Bconstat) 0; 

/* 

Funktionszeiger */ 

$04 

LONG 

(*Bconin) () ; 



$08 

LONG 

(*Bcostat) (); 



$0C 

void 

(*Bconout) () ; 



$10 

ÜLONG 

(*Rsconf) () ; 



$14 

IOREC 

*iorec; 

/* 

Zeiger auf lOREC-Struktur */ 


} MAPTAB; 




MD (Memory Descriptor) 


Offset 

Struktur 




$00 

typedef struct md 
{ 

struct md *m_link; 

/* 

Zeiger auf nächsten MD */ 

$04 

LONG 

m start; 

/* 

Anfangsadresse des Blocks */ 

$08 

LONG 

m length; 

/* 

Länge des Blocks */ 

$0C 

BASEPAGE 

*m own; 

/* 

Zeiger auf Prozeß-Beschreibungs- 


} MD; 



Struktur */ 


METAHDR 


Offset 

Struktur 


typedef struct 

i 


$00 

WORD mf header; 

/* -1 (Metafile-Kennung) */ 

$02 

WORD mf hlength; 

/* Länge des Headers in Integers 



(24) */ 
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Offset 


Struktur 


$04 


WORD mf version; 


/* 


$06 

$08 


WORD mf_ndcrcfl; /* 

WORD mf extents[4]; /* 


$10 


WORD mfjpages z[2]; /* 


bei der aktuellen Version 101 
(Version 1.01), Formel: 
100*Hauptnummer+Unternummer */ 
NDC/RC-Flag (0 oder 2) */ 
optional - maximale Ausmaße der 
Grafik - können mit 
"v__meta_extents () " gesetzt wer¬ 
den (sonst mit Null gefüllt) */ 
optional - Seitengröße in l/10mm 
- kann mit "vmjpagesize()" ge¬ 
setzt werden (sonst mit Nullen 


$14 


$1C 

$1E 


WORD mf_coords[4]; 

WORD mf_imgflag; 

WORD mf_resvd[9]; 

} METAHDR; 


gefüllt) */ 

/* optional - Koordinatensystem - 
kann mit "vm_coords{)" gesetzt 
werden (sonst mit Nullen ge¬ 
füllt) */ 

/* falls Bit 0=1, so enthält die 
Datei Bitimages, sonst nicht. 

Die anderen Bits sind immer 0.*/ 
/* zur Zeit unbenutzt */ 


METAINFO 


Offset 

Struktur 



typedef struct 
/ 

$00 

ULONG 

drivemap; /* Tabelle mit Bits für die Meta-DOS- 
Gerätetreiber "A".."Z" 

(Bit 0: "A”) */ 

$04 

char 

*version; /* Zeichenkette mit Namen und 

Versionsnummer von Meta-DOS */ 

$08 

LONG 

reserved[2]; 


} METAINFO; 
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MEVENT (Multi event) 


Offset 

Struktur 


typedef 

/ 

struct 

$00 

UWORD 

e_flags; 

$02 

UWORD 

e_bclk; 

$04 

UWORD 

e bmsk; 

$06 

UWORD 

e_bst; 

$08 

UWORD 

e mlflags; 

$0A 

GRECT 

e ml; 

$12 

UWORD 

e__m2flags; 

$14 

GRECT 

e m2; 

$1C 

WORD 

*e_mepbuf; 

$20 

ULONG 

e time; 

$24 

WORD 

e_mx; 

$26 

WORD 

e_my; 

$28 

UWORD 

e mb; 

$2A 

UWORD 

e_ks; 

$2C 

UWORD 

e kr; 

$2E 

UWORD 

e_br; 

$30 

UWORD 

e_m3flags; 

$32 

GRECT 

e_m3; 

$3A 

WORD 

e xtraO; 

$3C 

WORD 

*e smepbuf, 

$40 

ULONG 

e_xtral ; 

$44 

ULONG 

e_xtra2; 


} MEVENT 

r 


MFDB (Memory Form Definition Block) 


Offset 

Struktur 


typedef struct 
{ 

void *fd addr; 


$00 

/* Zeiger auf Speicherblock (muß auf ge¬ 
rader Adresse liegen). Für den Bild¬ 
speicher muß man NULL übergeben, alle 
anderen Werte werden dann ignoriert/* 
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Offset Struktur 

$04 WORD fd_w; ' /* Breite des Speicherblocks in 

Punkten */ 

$06 WORD fd_h; /* Höhe des Speicherblocks in 

Punkten */ 

$08 WORD fd__wdwidth; /* Breite des Speicherblocks in 

16-Bit-Worten */ 

$0A WORD fd_stand; /* 0: geräteabhängiges Format, 

1: Standardformat */ 

$0C WORD fd_nplanes; /* Anzahl der Bildebenen */ 

$0E WORD fd_rl, fd_r2,fd__r3; /* reserviert */ 

} MFDB; 


MFORM (Mouse form) 


/* X-Pos. Aktionspunkt */ 

/* Y-Pos. Aktionspunkt */ 

/* Anzahl planes (=1) */ 

/* Maskenfarbe (normal: 0) */ 
/* Zeigerfarbe (normal: 1) */ 
/* Maskenform */ 

/* Zeigerform */ 


MPB (Memory Parameter Block) 

Offset Struktur 

typedef struct 

{ 

$00 MD *mp_mfl; /* Zeiger auf "Memory Free List" */ 

$04 MD *mp_mal; /* Zeiger auf "Memory Allocated List" */ 

$08 MD *mp_rover; /* roving pointer; nur intern benötigt */ 

} MPB; 


Offset Struktur 

typedef struct 

{ 

$00 WORD mf_xhot; 

$02 WORD mf_yhot; 

$04 WORD mf_nplanes; 

$06 WORD mf_fg; 

$08 WORD mf_bg; 

$0A WORD mf_mask[16]; 

$2A WORD mfjdata [16] ; 

} MFORM; 
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OBJECT 


Offset 

Struktur 


typedef struct 
/ 


$00 

WORD 

ob next; 

/* Nummer des nächsten Objekts*/ 

$02 

WORD 

ob head; 

/* Nummer des ersten Kinds */ 

$04 

WORD 

ob tail; 

/* Nummer des letzten Kinds */ 

$06 

DWORD 

ob type; 

/* Art des Objekts */ 

$08 

UWORD 

ob flags; 

/* Verschiedene Flags */ 

$0A 

DWORD 

ob state; 

/* Status des Objekts */ 

$0C 

void 

*ob spec; 

/* Typabhängig */ 

$10 

WORD 

ob x; 

/* X-Position (rel. zum Parent- 




Objekt) */ 

$12 

WORD 

ob__y; 

/* Y-Position (rel. zum Parent- 




Objekt) */ 

$14 

WORD 

ob width; 

/* Breite */ 

$16 

WORD 

ob height; 

/* Höhe */ 


} OBJECT; 




OHEADER (Header einer DR-Objekdatei) 

Offset Struktur 

typedef struct 

{ 

$00 WORD magic; /* $601A */ 

$02 LONG tsize; /* Größe des Textsegments */ 

$06 LONG dsize; /* Größe des DATA-Segments */ 

$0A LONG bsize; /* Größe der BSS */ 

$0E LONG ssize; /* Größe der Symboltabelle */ 

$12 char reserved[10]; /* alle auf 0 setzen */ 

} OHEADER; 
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OSHEADER 

Offset Struktur 

typedef struct _osheader 

{ 

$00 UWORD os_entry; /* BRAnch-Instruktion zum RESET- 

Händler, Offset $00 */ 

$02 UWORD os_version; /* TOS-Versionsnummer, 

Offset $02 */ 

$04 void *reseth; /* Zeiger auf RESET-Handler, 

Offset $04 */ 

$08 struct _osheader *os_beg; 

/* Basisadresse des Betriebs¬ 
systems, Offset $08 */ 

$0C void *os_end; /* Erstes nicht vom OS benutztes 

Byte, Offset $0C */ 

$10 LONG os_rsvl; /* reserviert, Offset $10 */ 

$14 GEM_MUPB *os_magic; /* Zeiger auf "GEM memory usage 

Parameter block",Offset $14*/ 

$18 LONG osjdate; /* TOS-Herstellungsdatum im BCD- 

Format, etwa $02061986 für 
6. Febr. 1986, Offset $18 */ 

$1C UWORD os_conf; /* verschiedene Konfigurations¬ 

bits, Offset $1C */ 

$1E UWORD os_dosdate; /* TOS-Herstellungsdatum im 

GEMDOS-Format, Offset $1E */ 
/* die folgenden Felder erst ab TOS-Version 1.02 */ 

$20 char **p_root; /* Basisadresse des GEMDOS- 

Pools, Offset $20 */ 

$24 BYTE **pkbshift; /* Zeiger auf BlOS-interne 

Variable für den aktuellen 
Wert von "Kbshift()", 

Offset $24 */ 

$28 BASEPAGE **p_run; /* Adresse der Variablen, die 

einen Zeiger auf den aktuel¬ 
len GEMDOS-Prozeß enthält, 
Offset $28 */ 

$2C char *p_rsv2; /* reserviert, Offset $2C */ 

} OSHEADER; 
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PARMBLK 


Offset 

Struktur 


typedef struct 
r 


$00 

i 

OBJECT 

*pb tree; 

/* Zeiger auf Objektbaum */ 

$04 

WORD 

pb_obj; 

/* Objektnummer */ 

$06 

WORD 

pb prevstate; 

/* Vorheriger Status */ 

$08 

WORD 

pb currstate; 

/* Neuer Status */ 

$0A 

WORD 

pb_x; 

/* X-Position des Objekts */ 

$0C 

WORD 

pbj/; 

/* Y-Position des Objekts */ 

$0E 

WORD 

pb_w; 

/* Breite */ 

$10 

WORD 

pbji; 

/* Höhe */ 

$12 

WORD 

pb_xc; 

/* X-Position des Begrenzungs¬ 




rechtecks */ 

$14 

WORD 

pb_yc; 

/* Y-Position des Begrenzungs¬ 




rechtecks */ 

$16 

WORD 

pb_wc; 

/* Breite des Begrenzungs¬ 




rechtecks */ 

$18 

WORD 

pb_hc; 

/* Höhe des Begrenzungs¬ 




rechtecks */ 

$1A 

LONG 

pb parm; 

/* Parameter aus USERBLK */ 


} PARMBLK; 



/* Zeiger auf Bildschirmanfang */ 
/* dazu zu addierender Offset */ 
/* Bildschirmbreite in Punkten */ 
/* Bildschirmhöhe in Punkten */ 

/* Linker Rand in Punkten */ 

/* Rechter Rand in Punkten */ 

/* Auflösung */ 

/* Druckertyp Atari/Epson */ 


PBDEF (Printblk Definition) 

Offset Struktur 

typedef struct 

{ 

$00 LONG pb_scrptr; 

$04 WORD pb_offset; 

$06 WORD pb_width; 

$08 WORD pb_height; 

$0A WORD pb_left; 

$0C WORD pb_right; 

$0E WORD pb_screz; 

$10 WORD pbjprrez; 
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Offset 

Struktur 

$12 

LONG pb colptr; 

/* 

Zeiger auf Farbpalette (zum Bei¬ 
spiel $FF8240) */ 

$16 

WORD pb_prtype; 

/* 

0: Atari Matrix monochrom, 

1: Atari Matrix farbig, 

2: Atari Typenrad monochrom, 

3: Epson Matrix monochrom */ 

$18 

WORD pb_prport; 

/* 

Schnittstelle Centronics/RS 232 */ 

$1A 

LONG pb mask; 

/* 

Zeiger auf Halbtonmaske */ 


} PBDEF; 



PH (Program Header) 



Offset 

Struktur 




typedef struct 
{ 

WORD ph branch; 



$00 

/* 

Branch an den Anfang des Programms 
(OxfiOlA) */ 


$02 

LONG ph_tlen; 

/* 

Länge des TEXT-Abschnitts */ 

$06 

LONG ph__dlen; 

/* 

Länge des DATA-Abschnitts */ 

$0A 

LONG ph_blen; 

/* 

Länge des BSS-Abschnitts */ 

$0E 

LONG ph_slen; 

/* 

Länge der Symboltabelle */ 

$12 

LONG ph_resl; 

/* 

reserviert; muß 0 sein */ 

$16 

LONG ph_prgflags; 

/* 

spezielle Flags */ 

$1A 

WORD ph__absflag; 

/* 

0: Relozierungsinformationen 
vorhanden */ 


} PH; 




PUNINFO (Physical Unit Information) 


Offset 

Struktur 


typedef 

{ 

WORD 

struct 



$00 

puns; 

/* 

Anzahl der Geräte */ 

$02 

BYTE 

pun[16]; 

/* 

diverse Flags */ 

$12 

LONG 

part_start[16]; 

/* 

Partitionsanfänge */ 
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Offset 

Struktur 

$52 

LONG 

P_cookie; 

/* 

muß "AHDI" sein */ 

$56 

LONG 

*P cookptr; 

/* 

zeigt auf das vorherige 





Element */ 

$5A 

UWORD 

P Version; 

/* 

0x0300 oder größer */ 

$5C 

UWORD 

P__max_sector ; 

/* 

maximale Sektorgröße */ 

$5E 

LONG 

reserved[16]; 




} PUNJTNFO; 




RSHDR (Resource Header) 


Offset 

Struktur 



typedef struct 
/ 


$00 

i 

UWORD 

rshjvrsn; 

/* 

$02 

UWORD 

rsh_object; 

/* 

$04 

UWORD 

rsh_tedinfo; 

/* 

$06 

UWORD 

rsh_iconblk; 

/* 

$08 

UWORD 

rsh bitblk; 

/* 

$0Ä 

UWORD 

rsh_frstr; 

/* 

$0C 

UWORD 

rsh String; 

/* 

$0E 

UWORD 

rsh_imdata; 

/* 

$10 

UWORD 

rsh frimg; 

/* 

$12 

UWORD 

rsh trindex; 

/* 

$14 

UWORD 

rsh nobs; 

/* 

$16 

UWORD 

rsh_ntree; 

/* 

$18 

UWORD 

rsh nted; 

/* 

$1A 

UWORD 

rsh_nib; 

/* 

$1C 

UWORD 

rsh nbb; 

/* 

$1E 

UWORD 

rsh_nstring; 

/* 

$20 

UWORD 

rsh__nimages; 

/* 

$22 

UWORD rsh rssize; 

} RSHDR; 

/* 


null */ 

Position des Objekt-Feldes */ 
Position der TEDINFO-Strukturen * 
Position der ICONBLK-Strukturen * 
Position der BITBLK-Strukturen */ 
Position der freien Strings */ 
unbenutzt */ 

Position der Image-Daten */ 
Position der freien Images */ 
Position der Objektbaumtabelle */ 
Gesamtzahl der Objekte */ 
Gesamtzahl der Objektbäume */ 
Gesamtzahl der 
TEDINFO-Strukturen */ 

Gesamtzahl der 
ICONBLK-Strukturen */ 

Gesamtzahl der 
BITBLK-Strukturen */ 

Gesamtzahl der Strings */ 
Gesamtzahl der Images */ 
Gesamtlänge der RSC-Datei */ 


/ 

/ 
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TEDINFO 


Offset 

l Struktur 


typedef struct - 
1 / 



$00 

i 

char *te_ptext; 

/* 

Zeiger auf Text */ 

$04 

char *te ptmplt; 

/* 

Zeiger auf Textmaske */ 

$08 

char *te_pvalid; 

/* 

Zeiger auf Texttypmaske */ 

$0C 

WORD te font; 

/* 

Zeichensatz */ 

$0E 

WORD te__resvdl; 

/* 

reserviert */ 

$10 

WORD te just; 

/* 

Justifikation */ 

$12 

WORD te_Color; 

/* 

Farbe des betreff. Rechtecks */ 

$14 

WORD te resvd2; 

/* 

reserviert */ 

$16 

WORD te__thickness; 

/* 

Rahmen */ 

$18 

WORD te_txtlen; 

/* 

Länge des Textes */ 

$1A 

WORD te_tmplen; 

/* 

Länge der Textmaske */ 


} TEDINFO; 




USERBLK 

Offset Struktur 

typedef struct 

{ 

$00 WORD (*ub_code)(PARMBLK *);/* Zeiger auf die eigene 

Funktion */ 

$04 LONG ub_parm; /* Ein optionaler Parameter */ 

} USERBLK; 

VDIESC 

Offset Struktur 

typedef struct 

{ 

-$38E LONG RESERVED6; /* (-$38E) */ 

~$38A FONT_HDR *CUR_FONT; 

/* Zeiger auf den Header des aktuel¬ 
len Zeichensatzes (~$38A) */ 
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Offset 

Struktur 


-$386 

WORD EESERVED5[23]; 

/* 

-$358 

WORD M_POS_HX; 

/* 

-$356 

WORD M_POS_HY; 

/* 

-$354 

WORD M_PLANES; 

/* 

-$352 

WORD M__CDB_BG; 

/* 

-$350 

WORD M_CDB_FG; 

/* 

-$34E 

WORD MASK_FORM[32]; 

/* 

-$30E 

WORD INQ_TABt45]; 

/* 

-$2B4 

WORD DEV_TAB[45]; 

/* 

-$25A 

WORD GCURX; 

/* 

-$258 

WORD GCÜRY; 

/* 

-$256 

WORD M_HID_CT; 

/* 

-$254 

WORD MOUSE_BT; 

/* 

-$252 

WORD REQJ20L[48]; 

/* 

-$1F2 

WORD SIZ_TAB[15]; 

/* 

-$1D4 

WORD RESERVED4[2]; 


-$1D0 

LONG CÜR__WORK; 

/* 

-$1CC 

FONT_HDR *DEF_FONT 

f 

/* 

-$1C8 

LONG FONT_RING[4]; 

/* 


(-$386) */ 

X-Koordinate 'des Maus-"Hot spot" 
(-$358) */ 

Y-Koordinate des Maus-"Hot spot" 
(-$356) */ 

Maus wird im Replace-Modus (1) 
oder im XOR-Modus (-1) gezeichnet 
(-$354) */ 

Maus-Hintergrundfarbe (-$352) */ 
Maus-Vordergrundfarbe (-$350) */ 
jeweils abwechselnd für Vorder¬ 
grund und Maske 16 Words 
(-$34E) */ 

Informationen, die bei 
"vq_extnd()" zurückgeliefert wer¬ 
den (-$30E) */ 

Informationen, die man bei 
"v_opnwk()" erhält (—$2B4) */ 
Aktuelle X-Position der Maus 
(-$25A) */ 

Aktuelle Y-Position der Maus 
(-$258) */ 

Anzahl der erfolgten "Hide Mouse"- 
Aufrufe (-$256) */ 

Aktueller Status der Mausknöpfe 
(-$254) */ 

Interne Daten für "vq_color ()" 
(-$252) */ 

Informationen, die bei "v_opnwk()" 
zurückgeliefert werden (-$1F2) */ 

Zeiger auf Attributdaten der aktu¬ 
ellen virtuellen Workstation 
(-$1D0) */ 

Zeiger auf den Standard- 
Systemzeichensatz (-$1CC) */ 

Drei Pointer auf Zeichensatzlisten 
(verkettete FONT_HDR-S'trukturen). 
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Offset 

Struktur 

-$1B8 

WORD FONT_COUNT; 

-$1B6 

WORD RESERVED3[45] 

-$15C 

CHÄR CUR_MS_STAT; 

-$15B 

CHAR RESERVED2; 

-$15A 

WORD V_HID_CNT; 

-$158 

WORD CUR_X; 

-$156 

WORD CÜR__Y; 

-$154 

CHAR CUR_FLAG; 

-$153 

CHAR M0USE_FLAG; 

-$152 

LONG RESERVED1 ; 

-$14E 

WORD V_SAV_XY[2] ; 

-$14A 

WORD SAVE_LEN; 

-$148 

LONG SAVE_ADDR; 

-$144 

WORD SAVE_STAT; 

-$142 

LONG $AVE_AREA[64] 




Das letzte Element enthält eine 0 
als Endezeichen (-$1C8) */ 

/* Anzahl der Zeichensätze in der 
"FONT RING"-Liste (-$1B8) */ 


Mausstatus: 

Bit 

0: 

linker Knopf 

Bit 

1: 

rechter Knopf 

Bit 

2. .4: 

reserviert 

Bit 

5: 

Bewegungsflag 

(1: Maus wurde bewegt) 

Bit 

6: 

gesetzt: Status des 
rechten Knopfes hat sich 
geändert 

Bit 

7: 

gesetzt: Status des 


linken Knopfes hat sich 
geändert 

(-$15C) */ 


/* Anzahl der Hide-Cursor-Aufrufe */ 
/* X-Position der Maus (-$158) */ 

/* Y-Position der Maus (-$156) */ 

/* <>0, wenn Mauszeiger beim nächsten 
VBlank neu gezeichnet werden muß 
(-$154) */ 

/* <>0, wenn Maus-Interruptbehandlung 
eingeschaltet ist (-$153) */ 

/* gerettete X- und Y-Koordinate des 
Cursors (-$14E) */ 

/* Anzahl der gebufferten Bildzeilen 
(-$14A) */ 

/* Adresse des ersten gebufferten 
Bytes im Bildspeicher (-$148) */ 

/* Bit 0: Buffer ist gültig(1) oder 
ungültig (0), Bit 1: Longs (1) 
oder Words (0) gebuffert (-$144)*/ 
/* Buffer für Bild unter Mauszeiger 
($-142) */ 
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Offset 

Struktur 

-$42 

LONG USER_TIM; 

-$3E 

LONG NEXT_TIM; 

-$3A 

LONG USERJBUT; 

-$36 

LONG ÖSER_CUR; 

-$32 

LONG USER JOT; 

-$2E 

WORD V_CELJiT; 

-$2C 

WORD V_CEL_MX; 

-$2A 

WORD V_CEL_MY; 

-$28 

WORD V_CEL_WR; 

-$26 

WORD V_COL_BG; 

-$24 

WORD V_COL_FG; 

-$22 

LONG V_CÜR__AD; 

-$1E 

WORD V_CUR_0F; 

-$1C 

WORD V_CUR_XY[2]; 

-$18 

CHAR VJPERIOD; 

-$17 

CHAR V_CUR_CT; 

~$16 

LONG V_FNT_AD; 

-$12 

WORD V FNT ND; 

-$10 

WORD VJFNTjST; 




/* aktueller Timer-Interrupt-Vektor; 
sollte zur Beendigung zu 
"NEXTJTM" springen (-$42) */ 

/* alter Timer-Interrupt-Vektor 
(-$3E) */ 

/* Maustastenvektor (~$3A) */ 

/* Mausvektor (-$36) */ 

/* Mausbewegungsvektor (-$32) */ 

/* Zeichenhöhe (-$2E) */ 

/* maximale Cursor-Spaltenposition 
(-$2C) */ 

/* maximale Cursor-Zeilenposition 
<-$2A) */ 

/* Characterzeilenbreite in Bytes 
(Höhe * Breite einer Pixelzeile) 
£-$28) */ 

/* Hintergrundfarbe (-$26) */ 

/* Vordergrundfarbe (-$24) */ 

/* Adresse der aktuellen 

Cursorposition auf dem Bildschirm 
(-$ 22 ) */ 

/* Vertikaler Offset vom physikali¬ 
schen Bildschirmanfang (kann mit 
VDI ESC 101 verändert werden) 

(-$1E) */ 

/* X- und Y-Position des Cursors 
<-$lC) */ 

/* Blinkgeschwindigkeit des Cursors 
(-$18) */ 

/* Zähler für Cursorblinken (-$17) */ 
/* Zeiger auf Zeichensatzdaten des 
Systemzeichensatzes (siehe auch 
VDI ESC 102). Die Zeichenbreiten 
müssen jeweils 8 Bytes betragen! 
(-$16) */ 

/* ASCII-Wert des letzten Zeichens im 
Zeichensatz (-$12) */ 

/* ASCII-Wert des ersten Zeichens im 
Zeichensatz (-$10) */ 
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Offset | 

Struktur 

-$0E 

WORD V_FNT_WD; 

/* 

Breite der Fontdaten (des 

Fontimage) in Bytes (~$E) */ 

-$0C 

WORD V_REZ_HZ; 

/* 

Bildschirmbreite in Pixel (-$0C )*/ 

-$oa ; 

LONG V_OFF_AD; 

/* 

Zeiger auf Zeichensatz-Offset- 
Tabelle (s. VDI ESC 102) (-$0A) */ 

-$06 | 

WORD RESERVED; 

/* 

TOS 1.00: Cursorflag (-$06) */ 

-$04 

WORD VJREZ_VT; 

/* 

Bildschirmhöhe in Pixel (-$04)*/ 

-$02 

WORD BYTES_LIN; 

/* 

Bytes pro Pixelzeile (-$02) */ 


} VDIESC; 



XBRA 




Offset 

Struktur 




typedef struct 
{ 

char xbjmagic[4]; 



$00 

/* 

"XBRA" = 0x58425241 */ 

$04 

char xb id(4]; 

/* 

vier Buchstaben lange Kennung wie 
beim Cookie Jar */ 

$08 

LONG xb__oldvec; 

/* 

ursprünglicher Wert des Vektors */ 


} XBRA; 




XCPB 


Offset 

Struktur 





typedef 

{ 

WORD 

struct 



$00 

handle; 

/* 

aus graf_handle()-Aufruf von 
XControl, Wichtig für 
v_opnvwk()!! */ 

$02 

WORD 

booting; 

/* 

ungleich 0: Initialisierung/ 
BootVorgang */ 

$04 

WORD 

reserved; 

/* 

reserviert */ 

$06 

WORD 

SkipRshFix; 

/* 

ungleich: Res ourcekoordinaten 
bereits transformiert */ 
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ATARI Profibuch 


Offset 


$08 

$0C 

$10 


$14 

$18 


$1C 


$20 


$24 


$28 


$2C 


Struktur 


void *reservel; /* reserviert */ 

void *reserve2; /* reserviert */ 

void cdecl (*rsh_fix)(WORD num_objs, WORD num_frstr, 

WORD nuitjfrimg, WORD nurrjtree, 
OBJECT *rs_object, 

TEDINFO *rs_tedinfo, 
char *rs_strings[], 

ICONBLK *rs__iconblk, 

BITBLK *rs_bitblk, 

long *rs_frstr, 

long *rs_frimg, 

long *rs_trindex, 

struct foobar *rs_imdope) ; 

void cdecl (*rsh_obfix)(OBJECT *tree, WORD curob); 

WORD cdecl (*Popup) (char *items[], WORD numjLtems, 

WORD default_item, 

WORD font_size, GRECT fbutton, 
GRECT *world); 

void cdecl (*Sl_size)(OBJECT *tree, WORD base, 

WORD slider, WORD numjLtems, 
WORD visible, WORD direction, 
WORD minjsize); 

void cdecl (*Sl_x)(OBJECT *tree, WORD base, 

WORD slider, WORD value, 

WORD numjnin, WORD num_max, 
void (*foo)(void)); 

void cdecl (*Sl_y)(OBJECT *tree, WORD base, 

WORD slider, WORD value, 

WORD numjnin, WORD numjmax, 
void (*foo)(void)); 

void cdecl (*Sl_arrow) (OBJECT *tree, WORD base, 

WORD slider, WORD obj, 

WORD inc, WORD min, WORD max, 
WORD *numvar, WORD direction, 
void (*foo)(void)); 

void cdecl (*Sljdragx)(OBJECT *tree, WORD base, 

WORD slider, WORD min, 

WORD max, WORD *numvar, 
void (*foo)(void)); 


Angang B: Wichtige Betriebssystemstrukturen 
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Struktur 

void cdecl (*Sl_dragy)(OBJECT *tree, WORD base, 

WORD slider, WORD min, 

WORD max, WORD *numvar, 
void (*foo)(void)); 

WORD cdecl (*Xform_do)(OBJECT *tree, 

WORD start_field, 

WORD *puntmsg); 

GRECT * cdecl (*GetFirstRect)(GRECT *prect); 

GRECT * cdecl (*GetNextRect)(void); 

void cdecl (*Set_Evnt_Mask) (WORD mask, MOBLK *ml, 

MOBLK *m2, long time); 

WORD cdecl (*XGen_Alert)(WORD id); 

WORD cdecl (*CPX_Save) (void *ptr, long num); 

void * cdecl (*Get_Buffer)(void); 

WORD cdecl (*getcookie)(long cookie, long *p_value); 

WORD Country_Code; /* Länderkennung, analog zu der 

im OSHEADER - allerdings in 
fester Abhängigkeit von der 
XControl-Version */ 

void cdecl (*MFsave)(WORD saveit, MFORM *mf); 

} XCPB; 
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Anhang C: 

Tabelle der Tastatur-Scancodes 


Vorbemerkung: Normalerweise ist es nicht nötig, mit Scancodes zu arbeiten - für Control-Ta¬ 
stenkombinationen kann man statt dessen den ASCÜ-Code verwenden, für Altemate-Kombi¬ 
nationen bietet sich die Abfrage der XBIOS-Tastaturtabellen via “KeytblO” an. Die direkte 
Abfrage von Scancodes sollte also nur bei Sondertasten (wie den Cursortasten, Funktionstasten, 
UNDO etc.) nötig sein. 


Scancode 

Deutschland 

USA 

England 

Frankreich 

Standard- 

VDI-Code 

1 

ESC 





2 

1 

1 

1 

1 

1 

3 

2 

2 

2 

2 

2 

4 

3 

3 

3 

3 

3 

5 

4 

4 

4 

4 

4 

6 

5 

5 

5 

5 

5 

7 

6 

6 

6 

6 

6 

8 

7 

7 

7 

7 

7 

9 

8 

8 

8 

8 

8 

10 

9 

9 

9 

9 

9 

11 

0 

0 

0 

0 

0 

12 

ß 

— 

- 

) 

- 

13 

» 

= 

— 

- 

= 

14 

Backspace 





15 

TAB 





16 

Q 

Q 

Q 

A 

Q 

17 

w 

w 

w 

Z 

w 

18 

E 

E 

E 

E 

E 

19 

R 

R 

R 

R 

R 

20 

T 

T 

T 

T 

T 

21 

Z 

Y 

Y 

Y 

Y 

22 

u 

U 

U 

U 

U 

23 

I 

I 

I 

I 

I 

24 

0 

o 

0 

o 

0 

25 

p 

p 

P 

p 

P 

26 

ü 

[ 

[ 

[ 

[ 

27 

+ 

] 

] 

] 

] 

28 

Return 
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ATARI Profibuch 


Scancode 

Deutschland 

USA 

England 

Frankreich 

Standard- 

VDI-Code 

29 

30 

Control 

A 

A 

A 

Q 

A 

31 

S 

S 

s 

s 

S 

32 

D 

D 

D 

D 

D 

33 

F 

F 

F 

F 

F 

34 

G 

G 

G 

G 

G 

35 

H 

H 

H 

H 

H 

36 

J 

J 

J 

J 

J 

37 

K 

K 

K 

K 

K 

38 

L 

L 

L 

L 

L 

39 

Ö 

» 

9 

M 

9 

40 

Ä 

> 

’ 

\ 

» 

41 

# 

i 

‘ 

« 

< 

42 

43 

Shift links 

\ 

# 

@ 

\ 

44 

Y 

Z 

Z 

W 

z 

45 

X 

X 

X 

X 

X 

46 

C 

c 

c 

c 

c 

47 

V 

V 

V 

V 

V 

48 

B 

B 

B 

B 

B 

49 

N 

N 

N 

N 

N 

50 

M 

M 

M 

> 

M 

51 

» 

> 

9 

» 

9 

52 




: 


53 

- 

/ 

/ 

= 

/ 

54 

55 

Shift rechts 
nicht da 

nicht da 

nicht da 

nicht da 

PRINT 

56 

57 

58 

59 

60 

61 

62 

63 

64 

65 

Altemate 

Leertaste 

CapsLock 

Fl 

F2 

F3 

F4 

F5 

F6 

F7 




SCREEN 
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Scancode 

Deutschland 

USA 

England 

Frankreich 

Standard- 

VDI-Code 

66 

F8 





67 

F9 





68 

F10 





71 

ClrHome 





72 

t 





73 

nicht da 

nicht da 

nicht da 

nicht da 

PAGE UP 

74 

- (Zififemblock) 





75 

<— 





77 

-» 





78 

+ (Zififemblock) 





79 

nicht da 

nicht da 

nicht da 

nicht da 

END 

80 

1 





81 

nicht da 

nicht da 

nicht da 

nicht da 

PAGE 






DOWN 

82 

Insert 





83 

Delete 





84 

Shift-Fl 

Shift-Fl 

Shift-Fl 

Shift-Fl 

Fll 

85 

Shift-F2 

Shift-F2 

Shift-F2 

Shift-F2 

F12 

86 

Shift-F3 

Shift-F3 

Shift-F3 

Shift-F3 

Fl 3 

87 

Shift-F4 

Shift-F4 

Shift-F4 

Shift-F4 

F14 

88 

Shift-F5 

Shift-F5 

Shift-F5 

Shift-F5 

F15 

89 

Shift-F6 

Shift-F6 

Shift-F6 

Shift-F6 

F16 

90 

Shift-F7 

Shift-F7 

Shift-F7 

Shift-F7 

F17 

91 

Shift-F8 

Shift-F8 

Shift-F8 

Shift-FS 

F18 

92 

Shift-F9 

Shift-F9 

Shift-F9 

Shift-F9 

F19 

93 

Shift-FlO 

Shift-FlO 

Shift-FlO 

Shift-FlO 

F20 

94 

nicht da 

nicht da 

nicht da 

nicht da 

F21 

95 

nicht da 

nicht da 

nicht da 

nicht da 

F22 

96 

< 

nicht da 

\ 

< 

F23 

97 

Undo 




F24 

98 

Help 




F25 

99 

((Ziffemblock) 




F26 

100 

) (Ziffemblock) 




F27 

101 

/ (Zififemblock) 




F28 

102 

* (Ziffemblock) 




F29 

103 

7 (Ziffemblock) 




F30 

104 

8 (Ziffemblock) 




F31 

105 

9 (Ziffemblock) 




F32 
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ATARI Profibuch 


Scancode 

Deutschland 

USA 

England 

Frankreich 

Standard- 

VDI-Code 

106 

4 (Ziffemblock) 




F33 

107 

5 (Ziffemblock) 




F34 

108 

6 (Ziffemblock) 




F35 

109 

1 (Ziffemblock) 




F36 

110 

2 (Ziffemblock) 




F37 

111 

3 (Ziffemblock) 




F38 

112 

0 (Ziffemblock) 




F39 

113 

. (Ziffemblock) 




F40 

114 

Enter (Ziffembl.) 




CTRL PRINT 
SCREEN 

115 

nicht da 

nicht da 

nicht da 

nicht da 

CTRL f- 

116 

nicht da 

nicht da 

nicht da 

nicht da 

CTRL —> 

117 

nicht da 

nicht da 

nicht da 

nicht da 

CTRL END 

118 

nicht da 

nicht da 

nicht da 

nicht da 

CTRL 

PAGEDOWN 

119 

nicht da 

nicht da 

nicht da 

nicht da 

CTRL HOME 

120 

ALT 1 




ALT 1 

121 

ALT 2 




ALT 2 

122 

ALT 3 




ALT 3 

123 

ALT 4 




ALT 4 

124 

ALT 5 




ALT 5 

125 

ALT 6 




ALT 6 

126 

ALT 7 




ALT 7 

127 

ALT 8 




ALT 8 

128 

ALT 9 




ALT 9 

129 

ALTO 




ALTO 

130 

ALT ß 

ALT- 

ALT - 

ALT) 

ALT- 

131 

ALT ’ 

ALT = 

ALT = 

ALT- 

ALT = 

132 

nicht da 

nicht da 

nicht da 

nicht da 

CTRL 

PAGEUP 


Die Standard-VDI-Codes beziehen sich augenscheinlich auf eine amerikanische PC-Stan- 
dardtastatur. Die Tastencodes ab 131 dürfen nur für Applikationen interessant sein, die auch 
unter MS-DOS laufen sollen. Die darunterliegenden Codes, die man bisher mit der Atari-Ta¬ 
statur nicht erzeugen kann, könnten allerdings bei einer möglichen Änderung des Tastatur- 
Layouts wichtig werden! 
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Anhang D: 
ASCII-Zeichensatz 


Der ASCII-Zeichensatz (“American Standard Code for Information Interchange”) ist ein stan¬ 
dardisierter 7-Bit-Zeichensatz, der folglich nur 128 Zeichen definiert. Das achte Bit kann (wie 
beim Atari-Zeichensatz geschehen) für Erweiterungen dienen, wobei der so entstandene er¬ 
weiterte ASCII-Zeichensatz ab Zeichen 128 nicht mehr normiert ist. Neuere Normen sind 
“ISO-Latin’”(ein 8-Bit-Zeichensatz mit europäischen Sonderzeichen, der im UNIX-Bereich 
an Bedeutung gewinnt) und “UNICODE” (ein 16-Bit-Zeichensatz). 


Code 

Zeichen 

Beschreibung (in Klammern: deutsch) 

0 

NHL 

Null (Nil) 

1 

SOH (Ctrl-A) 

Start of Heading (Anfang des Kopfes) 

2 

STX (Ctrl-B) 

Start of Text (Anfang des Textes) 

3 

ETX (Ctrl-C) 

End of Text (Ende des Textes) 

4 

EOT (Ctrl-D) 

End of Transmission (Ende der Übertragung) 

5 

ENQ (Ctrl-E) 

Enquiry (Stationsaufforderung) 

6 

ACK (CtrI-F) 

Acknowledge (Positive Rückmeldung) 

7 

BEL (Ctrl-G) 

Bell (Klingel) 

8 

BS (Ctrl-H) 

Backspace (Rückwärtsschritt) 

9 

HT (Ctrl-I) 

Horizontal Tabulation (Horizontal-Tabulator) 

10 

LF (Ctrl-J) 

Line Feed (Zeilenvorschub) 

11 

VT (Ctrl-K) 

Vertical Tabulation (Vertikal-Tabulator) 

12 

FF (Ctrl-L) 

Form Feed (Formularvorschub) 

13 

CR (Ctrl-M) 

Carriage Return (Wagenrücklauf) 

14 

SO (Ctrl-N) 

Shift-out (Dauerumschaltung) 

15 

SI (Ctrl-O) 

Shift-in (Rückschaltung) 

16 

DLE (Ctrl-P) 

Data Link Escape (Datenübertragungsumschaltung) 

17 

DC1 (CtrI-Q) 

Device Control 1 (Gerätesteuerung 1) 

18 

DC2 (Ctrl-R) 

Device Control 2 (Gerätesteuerung 2) 

19 

DC3 (Ctrl-S) 

Device Control 3 (Gerätesteuerung 3) 

20 

DC4 (Ctrl-T) 

Device Control 4 (Gerätesteuerung 4) 

21 

NAK (Ctrl-U) 

Negative Acknowledge (Negative Rückmeldung) 

22 

SYN (Ctrl-V) 

Synchronous Idle (Synchronisierung) 

23 

ETB (Ctrl-W) 

End of Transmission Block 
(Ende des Datenübertragungsblocks) 

24 

CAN (Ctrl-X) 

Cancel (Ungültig) 

25 

EM (Ctrl-Y) 

End of Medium (Ende der Aufzeichnung) 
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Code 

Zeichen 

Beschreibung (in Klammern: deutsch) 

26 

SUB (Ctrl-Z) 

Substitute Character (Substitution) 

27 

ESC (Ctxi-D 

Escape (Fluchtzeichen) 

28 

FS (CtrlA) 

File Separator (Hauptgruppentrennung) 

29 

GS (Ctrl-]) 

Group Separator (Gruppentrennung) 

30 

RS (Ctrl- A ) 

Record Separator (Untergruppentrennung) 

31 

US (Ctrl-J 

Unit Separator (Teilgruppentrennung) 

32 

SP 

Space (Leerstelle) 

127 

DEL 

Delete (Löschen) 


Die Zeichen zwischen 32 und 127 entsprechen den Definitionen im Systemzeichensatz. 
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ATARI Profibuch 


Hex. 

Dez. 

Oktal 

Binär Zeichensatz 

Hex. 

Dez. 

Oktal 

Binär Zeichensatz 

60 

096 

140 

01100000 

' 

90 

144 

220 

10010000 

E 

61 

097 

141 

01100001 

a 

91 

145 

221 

10010001 

s 

62 

098 

142 

01100010 

b 

92 

146 

222 

1001B010 

fE 

63 

099 

143 

01100011 

c 

93 

147 

223 

10010011 

ö 

64 

100 

144 

01100100 

d 

94 

148 

224 

10010100 

ö 

65 

101 

145 

01100101 

e 

95 

149 

225 

10010101 

ö 

66 

102 

146 

01100110 

f 

96 

150 

226 

10010110 

ü 

67 

103 

147 

01100111 

9 

97 

151 

227 

10010111 

ü 

68 

104 

150 

01101000 

h 

98 

152 

230 

10011000 

y 

69 

105 

151 

01101001 

i 

99 

153 

231 

10011001 

ö 

60 

106 

152 

01101010 

j 

90 

154 

232 

10011010 

ü 

68 

107 

153 

01101011 

k 

98 

155 

233 

10011011 

$ 

6C 

108 

154 

01101100 

I 

9C 

156 

234 

10011100 

£ 

60 

109 

155 

01101101 

m 

9D 

157 

235 

10011101 

¥ 

6E 

110 

156 

01101110 

n 

9E 

158 

236 

10011110 

ß 

6F 

111 

157 

01101111 

□ 

9F 

159 

237 

10011111 

f 

70 

112 

160 

01110000 

P 

00 

160 

240 

10100000 

ä 

71 

113 

161 

01110001 

q 

01 

161 

241 

10100001 

l 

72 

114 

162 

01110010 

r 

02 

162 

242 

10100010 

6 

73 

115 

163 

01110011 

s 

03 

163 

243 

10100011 

ü 

74 

116 

164 

01110100 

t 

A4 

164 

244 

10100100 

n 

75 

117 

165 

01110101 

u 

05 

165 

245 

10100101 

N 

76 

118 

166 

01110110 

u 

06 

166 

246 

10100110 

a 

77 

119 

167 

01110111 

w 

07 

167 

247 

10100111 

0 

78 

120 

170 

01111000 

X 

08 

168 

250 

10101000 

ä 

79 

121 

171 

01111001 

y 

09 

169 

251 

10101001 

r 

7A 

122 

172 

01111010 

z 

AA 

170 

252 

10101010 

-i 

7B 

123 

173 

01111011 

{ 

OB 

171 

253 

10101011 

k 

7C 

124 

174 

01111100 

1 

AC 

172 

254 

10101100 

'4 

7D 

125 

175 

01111101 

> 

00 

173 

255 

10101101 

i 

7E 

126 

176 

01111110 

I\y 

OE 

174 

256 

10101110 

« 

7F 

127 

177 

01111111 

A 

AF 

175 

257 

10101111 

» 

80 

128 

200 

10000000 

c 

B0 

176 

260 

10110000 

a 

81 

129 

201 

10000001 

ü 

Bl 

177 

261 

10110001 

0 

82 

130 

202 

10000010 

e 

B2 

178 

262 

10110010 

0 

83 

131 

203 

10000011 

ä 

B3 

179 

263 

10110011 

0 

84 

132 

204 

10000100 

ä 

B4 

180 

264 

10110100 

OB 

85 

133 

205 

10000101 

ä 

85 

181 

265 

10110101 

C 

86 

134 

206 

10000110 

ä 

B6 

182 

266 

10110110 

fl 

87 

135 

207 

10000111 

C 

B7 

183 

267 

10110111 

fl 

88 

136 

210 

10001000 

e 

B8 

184 

270 

10111000 

0 

89 

137 

211 

10001001 

e 

B9 

185 

271 

10111001 

" 

80 

138 

212 

10001010 

e 

B0 

186 

272 

10111010 


8B 

139 

213 

10001011 

i" 

BB 

187 

273 

10111011 

t 

8C 

140 

214 

1000110B 

l 

BC 

188 

274 

10111100 

qi 

8D 

141 

215 

10001101 

i 

BD 

189 

275 

10111101 

© 

8E 

142 

216 

10001110 

Ä 

BE 

190 

276 

10111110 

® 

8F 

143 

217 

10001111 

fl 

BF 

191 

277 

10111111 

XX 
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Hex. Dez. Oktal Binar Zeichensatz Hex. Dez. Oktal 


C0 

192 

300 

11000000 

CI 

193 

301 

11000001 

C2 

194 

302 

11000010 

C3 

195 

303 

11000011 

C4 

19B 

304 

11000100 

C5 

197 

305 

11000101 

CB 

198 

306 

11000110 

C7 

199 

307 

11000111 

C8 

200 

310 

11001000 

C9 

201 

311 

11001001 

CA 

202 

312 

11001010 

CB 

203 

313 

11001011 

CC 

204 

314 

11001100 

CD 

205 

315 

11001101 

CE 

206 

316 

11001110 

CF 

207 

317 

11001111 

D0 

208 

320 

11010000 

Dl 

209 

321 

11010001 

D2 

210 

322 

11010010 

D3 

211 

323 

11010011 

D4 

212 

324 

11010100 

D5 

213 

325 

11010101 

DB 

214 

326 

11010110 

D7 

215 

327 

11010111 

DS 

216 

330 

11011000 

D9 

217 

331 

11011001 

DA 

218 

332 

11011010 

DB 

219 

333 

11011011 

DG 

220 

334 

11011100 

DD 

221 

335 

11011101 

DE 

222 

336 

11011110 

DF 

223 

337 

11011111 

E0 

224 

340 

11100000 

El 

225 

341 

11100001 

E2 

226 

342 

11100010 

E3 

227 

343 

11100011 

E4 

228 

344 

11100100 

E5 

229 

345 

11100101 

EB 

230 

346 

11100110 

E7 

231 

347 

11100111 

E8 

232 

350 

11101000 

E9 

233 

351 

11101001 

EA 

234 

352 

11101010 

EB 

235 

353 

11101011 

EC 

236 

354 

11101100 

ED 

237 

355 

11101101 

EE 

238 

356 

11101110 

EF 

239 

357 

11101111 


ij 

F0 

240 

360 

IJ 

Fl 

241 

361 

St 

F2 

242 

362 

1 

F3 

243 

363 

J 

F4 

244 

364 

1 

F5 

245 

365 

TT 

F6 

246 

366 

1 

F7 

247 

367 

T 

F8 

248 

370 

TT 

F9 

249 

371 

U 

FA 

250 

372 


FB 

251 

373 

3 

FC 

252 

374 

7 

FD 

253 

375 

D 

FE 

254 

376 

3 

FF 

255 

377 


D 

V 
3 
2 
P 
"1 
Qi 

n 

l 

l 

Q 

*1 

V 
§ 
A 

CO 

« 

ß 

r 

T 

I 

0 

JU 

f 

$ 

G 

Q 

6 

<P 

0 

e 

n 


Binär Zeichensntz 


11110000 
11110001 
11110010 
11110011 
11110100 f 

11110101 J 

11110110 r 
11110111 = 
11111000 ° 
11111001 * 
11111010 . 
11111011 
11111100 n 
11111101 2 
11111110 3 
11111111 


III +1 /NI VI 
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Anhang F: 

Patchvariablen im Festplattentreiber AHDI 


Die Programmdatei des Atari-Festplattentreibers AHDI enthält ab Version 3.00 mehrere zum 
Verändern freigegebene Patchvariablen (zu finden in “AHDI.PRG” bzw. “SHDRIVER.SYS”). 
Die modifizierbaren Werte beziehen sich auf GEMDOS-Pool und maximale Sektorgröße 
(siehe GEMDOS-Einleitung)sowiedieReservierungvonLaufwerkskennungenfürwechselbare 
Medien (siehe BIOS-Einleitung, “Unterstützung von Wechselplatten”). 

Die angegebenen Offsets beziehen sich auf das erste Byte der Programmdatei: 


Offset 

Größe 

Inhalt 

$28 

UWORD 

“Magic number” $F0AD. Nur dann, wenn hier der richtige Wert 
steht, dürfen die folgenden Werte verändert werden. 

$2A 

UWORD 

Versionsnummer, zum Beispiel $300 für AHDI 3.00. 

$2C 

UWORD 

Anzahl der zusätzlichen Einträge für den GEMDOS-Pool (nor¬ 
malerweise 128, wird nur in GEMDOS-Versionen vor 0.15 
benutzt, siehe Erläuterungen zu “FOLDR100.PRG’) 

$2E 

UWORD 

Maximale Sektorgröße (siehe in der GEMDOS-Einleitung: 
“GEMDOS-Puffer”) 

$30 

UWORD 

Anzahl der Einträge in der folgenden Tabelle (in Bytes) 

$32 

BYTE 

Anzahl der zu reservierenden Laufwerksbuchstaben, falls es 
sich um ein wechselbares Medium handelt (siehe BIOS-Einlei- 
tung: “Unterstützung von Wechselplatten”). 


Bemerkungen 

Neuere AHDI-Versionen (ab 4.00) haben für die SCSI-Geräte nicht etwa eine vergrößerte 
Tabelle, sondern eine zweite, zusätzliche. 
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Eine Datei mit Bildinformationen im IMG-Format trägt immer die Namenserweiterung 
“IMG”. Der Header der Datei hat die Gestalt: 

typedef struct 
{ 

UWORD im_version; /* Versionsnummer der Imagedatei */ 

DWORD imjieadlength; /* Länge des Headers in Words */ 

UWORD im_nplanes; /* Anzahl der Farbebenen */ 

UWORD imjpatlen; /* Musterlänge in Byte */ 

UWORD imjpixwidth; /* Pixelbreite in mm/1000 */ 

UWORD im_pix_height; /* Pixelhöhe in mm/1000 */ 

UWORD im_scanwidth; /* Zeilenbreite in Pixeln */ 

UWORD im_nlines; /* Anzahl der Scanlines */ 

} IMGHEADER; 

Die Länge des Headers muß immer überprüft werden, denn in künftigen GEM-Versionen 
könnte sich seine Länge (z. B. zur Aufnahme einer Farbpalette) ändern. Ältere Programme, 
die diese Mehrinformation nicht verarbeiten können, überspringen dann einfach den Rest der 
Struktur. Die Länge der Muster liegt zwischen 1 und 8; bei den meisten Bildschirmen beträgt 
die Musterlänge zwei Bytes. Jede Scanline-Information setzt sich aus zwei Komponenten 
zusammen: 

- Wiederholungsteil 

typedef struct 
{ 

WORD scjzero; /* immer 0 */ 

BYTE sc_ff; /* immer 255 (=0xFF) */ 

BYTE sc__cnt; /* Anzahl der kodierten Bildzeilen */ 

} SCANLINE; 


— eigentliche Bildinformation 

Die Bildinformationen werden in drei verschiedenen Kodierungen zeilenweise ab¬ 
gespeichert: 
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- Einfarbige Pixelfolgen (“Solid Run”) werden als einfaches Byte gespeichert, wobei das 
oberste Bit den Status des Punktes bestimmt (also “an” oder “aus”). Die restlichen sieben 
Bits teilen mit, wie viele Bytes ausgegeben werden sollen. 

- 48 gesetzte Pixel würden also als $86 ($80+$6) kodiert, acht nicht gesetzte Pixel als $06. 

- Musterfolgen (“Pattem Run”) haben als erstes Byte die 0 und als zweites die Anzahl der 
Musterwiederholungen. Die Musterlänge steht im Header unter “irnjpatlen”. Es folgen 
den ersten beiden Bytes also genau so viele Bytes, wie benötigt werden, um das Muster 
darzustellen. 

typedef struct 
{ 

BYTE pr_zero; /* immer 0 */ 

BYTE pr_cnt; /* Anzahl der Bytes */ 

BYTE pr_data[...]; /* Musterdaten */ 

} PATTERNRUN; 


- Schlecht oder nicht verkürzbare Bildinformation (“Bit String” 5 wird unverändert 
abgespeichert. Hier steht als erstes Byte eine $80 und als zweites die Anzahl der Bytes. 
Danachfolgen dann die entsprechenden Bytes mitderunkomprimiertenBildinformation. 

typedef struct 
{ 

BYTE bs_first; /* immer 0x80 */ 

BYTE bs_cnt; /* Anzahl der Bytes */ 

BYTE bs_data[..]; /* Bilddaten */ 

} BITSTRING; 


Es folgen jeweils die Bildinformationen für jede kodierte Farbebene direkt hintereinander. 
Man sollte auch darauf achten, daß immer eine Zeile mit voller Bytezahl codiert wird, auch 
wenn das Bild effektiv schmaler ist. 

Es können also bis zu sieben Bits “überflüssiger” Information vorliegen. Die Pixelbreite des 
Bildes steht im Dateikopf unter “im_scanwidth”. 

Leider ist das IMG-Format für die Arbeit mit Farbgrafiken nur sehr bedingt geeignet. Die 
GEM-Dokumentation spricht zwar von einer separaten Speicherung von Rot-, Grün-, Blau- 
und Grau-Informationen - wie das aber genau aussehen soll, ist unklar. 


Anhang G: Das IMG-Format für Rasterbilder 
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Mögliche Abhilfen: 

1. Farbpaletteninformation in einer begleitenden Metadatei (siehe VDI-Funktion 
“v_bit_image()”) ablegen. 

2. Anderes, leistungsfähigeres Bildformat verwenden (die PC- und Macintosh-Welt schei¬ 
nen darüber übereinzustimmen, daß TIFF das Format der Wahl ist). 

3. Einige Programme unterstützen auch das sogenannte “XIMG”-Format, das von Dieter 
und Jürgen Geiß vorgeschlagen und bei dem der Dateikopf um Paletteninformationen 
erweitert worden ist: 


Offset 

Größe 

Belegung 

$10 

LONG 

Konstante “XIMG” als ASCH-Zeichen 

$14 

WORD 

Farbmodell (0: RGB, 1: CMY, 2: Pantone) 

$16ff 

WORD 

jeweils drei 16-Bit-Werte pro Farbregister, im RGB- 
Modell mit der Standard-VDI-Farbbeschreibung (Rot-, 
Grün- und Blau-Wert in Promille) 


Das Feld “im_headlength” muß natürlich angesichts des längeren Dateikopfes entsprechend 
verändert werden. 
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Diese Kurzeinführung soll es Nicht-C-Programmierem erleichtern, die abgedruckten Bei¬ 
spiele und Bindings zu lesen. Sie erhebt keinen Anspruch auf Vollständigkeit und kann na¬ 
türlich ein “richtiges” C-Buch nicht ersetzen - ebensowenig, wie man in sieben Tagen alle Se¬ 
henswürdigkeiten Europas besichtigen kann. Alle Beispiele beziehen sich auf die relativ neue 
ANSI-Norm, wie sie weitestgehend von ‘Turbo-C’ und vollständig von GNU-CC implementiert 
wird. 


Operatoren 


Beispiel Ergebnis 


-a 

Negation von a 

*a 

Inhalt des Zeigers a 

& a 

Adresse der Variablen a 


logische Negation von a 

++a 

inkrementiere zunächst a und betrachte a dann 

a++ 

betrachte a und inkrementiere a anschließend 

--a 

dekrementiere zunächst a und betrachte a dann 

a— 

betrachte a und dekrementiere a anschließend 

sizeof (TYP) 

Größe des Datentyps TYP in Bytes 

sizeof (EXP) 

Größe des Ausdrucks EXP in Bytes 

(TYP) EXP 

Wert des Ausdrucks EXP wird nach Datentyp TYP konvertiert 

a + b 

a plus b 

a-b 

a minus b 

a * b 

a mal b 

a /b 

a durch b 

a % b 

a modulo b 

a»b 

a um b Bits nach rechts verschoben 

a«b 

a um b Bits nach links verschoben 

a <b 

ungleich Null, falls a < b 

a>b 

ungleich Null, falls a > b 

a <= b 

ungleich Null, falls a <= b 

a>= b 

ungleich Null, falls a >= b 

a — b 

ungleich Null, falls a = b 
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Beispiel 

Ergebnis 

a != b 

ungleich Null, falls a ungleich b 

a & b 

a bitweise undiert mit b 

a 1 b 

a bitweise oderiert mit b 

a A b 

a bitweise xoderiert mit b (excl. oder) 

a&& b 

a logisch undiert mit b 

a II b 

a logisch oderiert mit b 

!a 

NOTa 

a? EXP1:EXP2 

EXP1 falls a ungleich 0, sonst EXP2 

a =b 

a wird der Wert von b zugewiesen 

a += b 

zu a wird b addiert (*) 

a -= b 

von a wird b subtrahiert (*) 

a *= b 

a wird mit b multipliziert (*) 

a/=b 

a wird durch b geteilt (*) 

a %= b 

a wird der Rest von (a/b) zugewiesen (*) 

a »= b 

a wird um b Bits nach rechts geschoben (*) 

a «= b 

a wird um b Bits nach links geschoben (*) 

a &= b 

a wird mit b undiert (*) 

a 1= b 

a wird mit b oderiert (*) 

a A = b 

a wird mit b x-oderiert (*) 

EXP1 , EXP2 

erst wird EXP1, dann EXP2 ausgewertet; Resultat ist der Wert von 
EXP2 

a[] 

Feld-Selektor 

a->b 

Element b der Struktur, auf die a zeigt 

a.b 

Element b der Struktur, die bei a beginnt 
(*) Ergebnis ist jeweils der (neue) Wert von a 


Datentypen 

Folgende grundlegende Datentypen werden in diesem Buch verwendet: 


char hier paßt ein Zeichen hinein (Größe: 8 Bit) 

BYTE ganzzahliger Wert zwischen 0 und 255 (Größe: 8 Bit) 

WORD ganzzahliger Wert zwischen -32768 und 32767 (Größe: 16 Bit) 

UWORD ganzzahliger Wert zwischen 0 und 65535 (Größe: 16 Bit) 

LONG ganzzahliger Wert zwischen -2147483648 und 2147483647 (Größe: 32 Bit) 
ULONG ganzzahliger Wert zwischen 0 und 4294967295 (Größe: 32 Bit) 


Aus diesen “skalaren” Datentypen kann man neue Typen konstruieren. Das einfachste Bei¬ 
spiel ist ein Array in der Form: 
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TYPNAME Variablenname[Größe]; /* Kommentar: ein Array */ 

Ein Beispiel: 

WORD int_in[16]; 

deklariert also ein Feld mit Platz für 16 WORD-Variablen, Die Numerierung der Feldelemente 
beginnt im Gegensatz zu Pascal immer bei Null - die definierten Feldelemente liegen also 
zwischen int_in[0] und int_in[15]. 

C-Zeichenketten sind einfach nur Felder von “char”-Variablen, wobei das Ende durch ein 
Nullbyte gekennzeichnet ist. 

char fraget] = "Was soll das?"; 

reserviert also Platz für 14 Zeichen - 13 für die Zeichen und eines für das Nullbyte. 

Wichtig sind auch die Pointer, also Zeigervariablen. Bei vielen Betriebssystemaufrufen 
werden nicht die Daten selbst, sondern ein Zeiger darauf übergeben. Dies passiert meist dann, 
wenn die Information nicht in einen skalaren Datentyp paßt - zum Beispiel ein Dateiname. 
Eine Zeigerdeklaration sieht so aus: 

TYPNAME *Variablenname; /* Ein Zeiger */ 

Ein Beispiel: 

WORD *zeiger; /* Ein Zeiger auf ein WORD */ 

Zur Arbeit mit Zeigern braucht man zwei Operatoren, den zum Derefenzieren und 
zum Referenzieren. 

Ein Beispiel: 

WORD zahl; 

WORD *zeiger; 

zahl = 5; 
zeiger = &zahl; 

*zeiger = 7; 


/* zahl enthält den Wert 5 */ 

/* zeiger enthält die Adresse der Variablen 
zahl */ 

/* die Variable, auf die zeiger zeigt (also 
zahl) wird auf 7 gesetzt */ 
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Intern behandelt ein C-Compiler Felder und Zeigervariablen (fast) identisch. Dies äußert sich 
besonders anschaulich in der Gleichheit von 

"name [index]" und "* (name+index) " 

Damit stehen alle folgenden Ausdrücke für das gleiche: 

"name[0]", "*name" und "0[name]" 

Es genügt zu wissen, daß man in der Praxis Zeiger als Felder und umgekehrt betrachten kann. 

Komplizierter wird es da schon bei den Datenstrukturen, bei denen man mehrere einfachere 
Datentypen zu einer gemeinsamen Struktur zusammenfaßt: 


typedef struct 
{ 

WORD 




ob next; 

/* 

Nummer des nächsten Objekts */ 

WORD 

ob_head; 

/* 

Nummer des ersten Kinds */ 

WORD 

ob tail; 

/* 

Nummer des letzten Kinds */ 

UWORD 

objtype ; 

/* 

Art des Objekts */ 

DWORD 

ob__flags; 

/* 

Verschiedene Flags */ 

UWORD 

ob state; 

/* 

Status des Objekts */ 

ULONG 

ob spec; 

/* 

Typabhängig */ 

WORD 

ob_x; 

/* 

X-Position (rel. zum Parent- 
Objekt) */ 

WORD 

obj/; 

/* 

Y-Position (rel. zum Parent- 
Objekt) */ 

WORD 

ob width; 

/* 

Breite */ 

WORD 

} OBJECT; 

ob height; 

/* 

Höhe */ 


Dies würde in Pascal folgendermaßen aussehen: 

TYPE 

OBJECT = RECORD 

ob_next : integer; 
ob_head : integer; 
ob_tail : integer; 
objtype : integer; 
ob_flags : integer; 
ob_state : integer; 
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ob_spec : long_integer; 
ob_x : integer; 

ob_y : integer; 

ob_width : integer; 
ob_height : integer; 

END; 

Wer in keiner Hochsprache programmiert, wird sich mehr dafür interessieren, wie so eine 
Struktur im Speicher aussieht. Trifft ein Compiler auf eine Strukturdeklaration, dann reser¬ 
viert er zunächst einmal einen Speicherbereich mit der Gesamtgröße der Struktur, die sich aus 
der Summe der Strukturkomponenten berechnet. Beispiel: 

OBJECT box; 

Damit ist ein 24 Bytes großer Speicherbereich für die Datenstruktur reserviert. Was passiert, 
wenn man auf eine Strukturkomponente zugreift? 

box.ob_width =10; 

Der Compiler überlegt sich nun, wie groß alle in der Struktur davor liegenden Komponenten 
sind. Die Anwort ist - nicht überraschend - 20. Erzeugt wird also ein Assemblerbefehl, der 
ungefähr so aussieht: 

move.w #10, box+20 

Das heißt, daß jede Strukturkomponente einen festen Offset innerhalb der Objektstruktur hat, 
die wir auch im Anhang “Wichtige Betriebssystemstrukturen” angegeben haben. 

Komplizierter wird es schon bei so einer Anweisung; 

OBJECT *boxpnt; 
boxpnt~>ob_width=l0; 

Hier haben wir in “boxpnf ’ einen Zeiger auf ein Objekt. Erzeugt wird in diesem Fall ungefähr 
Assembler-Code der Form: 

move.1 boxpnt, aO 

move.w #10, 20(aO) 


Es wird also 20 zu der Adresse addiert, die in “boxpnt” steht und das Ergebnis als Zeiger¬ 
variable verwendet. 
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Für die vom Betriebssystem benutzten Strukturen sind die Offsets der einzelnen Komponenten 
natürlich fest definiert. Dies gilt allerdings im allgemeinen für C-Strukturen nicht. Ein C- 
Compüer kann durchaus zwischen den einzelnen Strukturkomponenten unbenutzte Bytes 
einfügen, um Laufzeitoptimierungen zu erreichen. Dies ist aber normalerweise bei Compilern 
auf Motorola-Systemen nicht der Fall - außer, es werden Fiillbytes eingefügt, um einen 
WORD- oder LONG-Wert auf eine gerade Adresse zu verschieben. 

Bitfelder sind enge Verwandte der normalen C-Strukturen - nur dieses Mal werden den ein¬ 
zelnen Bits eigene Namen zugewiesen: 

typedef struct 
{ 

unsigned character 
signed framesize 
unsigned framecol 
unsigned textcol 
unsigned textmode 
unsigned fillpattern 
unsigned interiorcol 
} bfobspec; 

Die Art und Weise, wie ein C-Compiler diese Bits anordnet, ist vom Compiler anhängig. 
Überall, wo im Profibuch Bitfelder auftauchen, gelten die Angaben für “Turbo-C”, das in 
diesem Fall folgende Aufteilung benutzen würde: 


8; /* Wert zw. 0 und 255 (8 Bits) */ 

8; /* Wert zw. -128 und 127 (8 Bits) */ 
4; /* Wert zwischen 0 und 15 (4 Bits)*/ 
4; 

1; /* 0 oder 1 */ 

3; /* Wert zwischen 0 und 7 (3 Bits) */ 
4; /* Wert zwischen 0 und 15 (4 Bits)*/ 


Bits 

Feldelement 

24..31 

character 

16..23 

framesize 

12..15 

framecol 

8..11 

textcol 

7 

textmode 

4. .6 

fillpattern 

0..3 

interiorcol 


Funktionen 

Eine C-Funktion ist - grob vereinfacht ausgedrückt - eine Reihe von Maschineninstruktionen, 
denen man einige Parameter übergibt und ein Ergebnis zurückerhält. Dazu ein Beispiel für 
eine Funktionsdeklaration in ANSI-C: 
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LONG Bconin (WORD dev); 

Eingabeparameter ist also ein WORD-Parameter namens “dev”, und zurückgeliefert wird von 
der Funktion ein LONG-Retumwert. Anstelle einfacher skalarer Datentypen können natürlich 
auch kompliziertere Datenstrukturen auftreten: 

BPB *Getbpb (WORD dev); /* Funktion liefert einen Zeiger auf eine 

BPB-Struktur */ 

Im folgenden Beispiel erhält die Funktion als ersten Parameter einen Zeiger auf eine Zeichen¬ 
kette: 

WORD Fcreate (char *fname, WORD attribs); 

Auf welche Art und Weise die Parameterübergabe erfolgt, kann für jeden C-Compiler 
unterschiedlich sein. Die im TOS benutzten Übergabemechanismen wurden natürlich durch 
den bei der Entwicklung von TOS benutzten Compiler (“Alcyon-C”) geprägt: 

Parameter werden von rechts nach links nacheinander auf dem Stack abgelegt. 

Der Rückgabewert wird im Datenregister DO übergeben. 

“Turbo-C” hingegen übergibt normalerweise mehrere Parameter inDaten-und Adreßregistern, 
was natürlich zu kürzeren und schnelleren Maschinencodes führt. Normalerweise kümmern 
sich die Standardbibliotheken um die notwendigen Anpassungen. Immer dann, wenn man di¬ 
rekt Betriebssystemfunktionen aufruft (zum Beispiel bei der Benutzung von “shell_p” oder 
bei der Programmierung von XControl-Erweiterungen), muß man ‘Turbo-C’ durch das 
Schlüsselwort “cdecl” anweisen, die “alte” Form der Parameterübergabe zu benutzen. Besit¬ 
zer anderer Compiler können dieses Schlüsselwort gefahrlos ignorieren. 


“void” und “const” 

Bei vielen Funktionen taucht auch das Schlüsselwort “void" auf. Je nach Kontext hat es eine 
geringfügig andere Bedeutung: 

- Allein vor einer Funktionsdeklaration stehend, gibt es an, daß die Funktion keinen sinn¬ 
vollen Wert zuriiddiefert. Beispiel: 

void Bconout (WORD dev, WORD c); 

- Als einziger Parameter einer Funktion legt es fest, daß die Funktion tatsächlich gar keine 
Parameter erhält. Beispiel: 
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DTA *Fgetdta (void); 

- Im Zusammenhang mit einer Zeigervariablen gibt es an, daß der Zeiger auf keinen 
bestimmten Datentyp zeigt. Solche “void”-Zeiger können jeder anderen Zeigervariablen 
zugewiesen werden. Beispiel: 

void *Malloc (LONG amount); 
char *zeichenkette; 

OBJECT *ein_objekt; 


zeichenkette = Malloc (20 * sizeof (char)); /* Platz für 20 

Zeichen */ 

ein_objekt = Malloc (sizeof (OBJECT)); /* Platz für 

OBJECT-St ruktur */ 

Anmerkung : Die Syntax in den ersten beiden Beispielen ist tatsächlich etwas merkwürdig. 
Logischere Schreibweisen wie 

Bconout (WORD dev, WORD c); 

bzw. 

DTA *Fgetdta () ; 

waren allerdings aus Gründen der Rückwärtskompatibilität zum “alten” C nicht möglich. 

Das Wörtchen “const” kommt meist bei Parametern von Funktionen vor und legt fest, daß die 
aufgerufene Funktion den Inhalt des Parameters nicht verändert. Beispiel: 

void print_it (const char *Zeichen); 

Hier bliebe also die Zeichenkette, auf die “Zeichen” zeigt, garantiert intakt. Aus Zeitgründen 
und wegen fehlender Dokumentation war es uns leider nicht möglich, diese Eigenschaft für 
jede einzelne Betriebssystemfunktion zu verifizieren. Dort, wo das Wort auftaucht, darf man 
aber davon ausgehen, daß die Daten tatsächlich nicht verändert werden. 


Kontrollstrukturen 

Und schließlich noch eine kurze Übersicht über die Kontrollstrukturen der Sprache C: 



Anhang H: Kurzeinführung in die Syntax der Programmiersprache C 


1277 


if (Ausdruck) 

Anweisung; 

Wenn der Ausdruck wahr (also ungleich Null) ist, wird die Anweisung ausgeführt, Überall 
dort, wo eine Anweisung stehen darf, kann auch ein ganzer Anweisungsblock eingefügt 
werden: 

if (Ausdruck) 

{ 

Anweisung!; 

Anweisung2; 

} 

Zusätzlich kann ein “else”-Zweig angefügt werden: 

if (Ausdruck) 

Anweisung!; 

eise 

Anweisung2; 

Für Fallunterscheidungen gibt es “switch”: 

switch (Ausdruck) 

1 

case Konstantei: Anweisungen... 

case Konstante2: Anweisungen... 

default: Anweisungen... 

} 

Zunächst wird der Wert des Ausdrucks ermittelt. Stimmt das Ergebnis mit einer der angegebe¬ 
nen Konstanten überein, dann werden alle folgenden Anweisungen bis zum ersten “break” 
bzw, bis zum Ende der switch-Struktur ausgeführt. Ist der errechnete Wert mit keiner der Kon¬ 
stanten identisch, wird bei “default” fortgefahren. Üblicherweise sehen daher switch-Anwei¬ 
sungen so aus: 

switch (wert) 

{ 

case KONSTANTEI: 
case KONSTANTE2: 

Anweisungen; 

break; 
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case K0NSTÄNTE3: 

Anweisungen; 

break; 

default: 

/* Fehlerbehandlung */ 
break; 

} 

C kennt mehrere Typen von Schleifen, die einfachste davon ist die while-Schleife: 

while (Ausdruck) 

Anweisung; 

Die Anweisung (oder der Anweisungsblock) wird also so lange ausgeführt, bis der Ausdruck 
nicht mehr wahr ist. Diese Form der Schleife ist abweisend, die Anweisung wird also dann gar 
nicht ausgeführt, wenn der Ausdruck gleich zu Beginn falsch ist. Anders bei: 

do 

Anweisung; 
while (Ausdruck); 

In diesem Fall erfolgt der erste Test erst nach dem ersten Schleifendurchlauf. Sowohl lei¬ 
stungsfähig als auch schwer lesbar ist die for-Schleife: 

for (Ausdruckl; Ausdruck2; Ausdruck3) 

Anweisung; 

ist eine Abkürzung für: 

Ausdruckl; 
while (Ausdruck2) 

{ 

Anweisung; 

Ausdruck3; 

1 

Dazu ein Beispiel: 

for <i =0; i < 10; i++) 
workin[i] = 0; 


/* Initialisierung */ 
/* Abbruchbedingung */ 


/* Schleifenzähler weiterführen */ 
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ist identisch mit: 
i = 0; 

while (x < 10) 

{ 

workinfi] = 0; 
i++; 


Es sei noch erwähnt, daß jeder der Ausdrücke und auch die Schleifenanweisung leer sein 
können: 

for <;;) /* Endlosschleife */ 

Anweisung; 

oder 

for ( ; i < 10; workin[i++] = 0) /* leere Anweisung */; 

Zum Abschluß noch “break” und “continue”: 

break: Ausführung der Schleife beenden und bei der nächsten auf die Schleife 

folgenden Anweisung fortsetzen. 

continue: Beginn des nächsten Schleifendurchlaufs erzwingen. 
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Nützliche Werkzeuge für Programmierer 


Neben den “großen” Entwicklungssystemen gibt es eine ganze Reihe von nützlichen Tools, 
die bei der Programmentwicklung unter TOS helfen können. Die folgende Auswahl erhebt 
keinen Anspruch auf Vollständigkeit, sondern spiegelt nur die Vorlieben der Autoren wieder. 
Speziell die Programme “SysMon” und “TempleMon” seien jedem engagierten Programmie¬ 
rer ans Herz gelegt - diese Werkzeuge machen das Debuggen von systemnahen Programmen 
eigentlich erst möglich! 


BigScreen 

BigScreen vom Profibuch-Autor Julian Reschke ermöglicht es, auf herkömmlichen ST-, STE- 
oder TT-Systemen eine größere Bildfläche zu simulieren. Damit ist es möglich, Programme 
auf Auflösungsunabhängigkeit zu testen oderauch ohne Grafikkarte Versuche inFarbauflösun- 
gen zu unternehmen. BigScreen läuft in allen Standardauflösungen des ST, STE und TT und 
erfordert eine TOS-Version größer gleich 1.04. Man bekommt es (zusammen mit Stefan 
Eissings Drucker-Spooler “SPEX”) bei der 

SciLab GmbH 
Isestraße 57 
D-W2000 Hamburg 13 


SysMon 

SysMon ist ein System-Monitor, der genau an der Schnittstelle zwischen Betriebssystem und 
anderen Programmen sitzt, die mit diesem Betriebssystem arbeiten. Der SysMon ermöglicht 
es, die Aufrufe an das Betriebssystem mitzuprotokollieren. Er ist auch in derLage, den Zustand 
einzelner Systemresourcen - wie Speicherblöcke und Systemvektoren - anzuzeigen. Monitor 
bedeutet aber auch, daß der Zustand des Systems nur beobachtet und nicht verändert werden 
kann. SysMon gliedert sich in zwei generelle Teile. Der erste Teil kann die Aufrufe von Sy¬ 
stemfunktionen mitprotokollieren (der Tracer), und der zweite Teil ist für die Anzeige von Sy¬ 
stemresourcen zuständig (der Monitor). 

Der Tracer unterstützt alle dokumentierten Systemfunktionen und ist in weiten Bereichen 
konfigurierbar. Er kann alle Aufrufe von Systemfunktionen durch das Betriebssystem oder 
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von Programmen mitprotokollieren. Einzelne Systemaufrufe können bei der Ausgabe unter¬ 
drückt und einzelne Programme vom Tracen ausgenommen werden. Die Ausgaben können 
über verschiedene Einstellungen den jeweiligen Bedürfnissen angepaßt werden. Es sind sehr 
viele Erweiterungen in den Tracer eingebaut. Es werden zum Beispiel alle bekannten Mes¬ 
sage-Protokolle, die zur Kommunikation zwischen Applikationen und den quasiparallelen 
Accessories dienen, unterstützt. Auch werden alle definierten Konstanten in Textform ausge¬ 
geben. Die Ausgaben des Tracers können auf einer zweiten Bildschirmseite geschehen, auf 
die RS-232-, Centronics- oder MIDI-Schnittstelle ausgegeben oder in einer Datei mitprotokol¬ 
liert werden. 

Der Monitor zeigt mehrere Informationen wie Speicherblöcke, Systemvektoren und Struktu¬ 
ren, die teilweise nur systemintem dokumentiert sind. Die Systemvektoren bestimmen, 
welche Programme auf einzelne Funktionen des Systems Einfluß nehmen. Die Speicheranzeige 
zeigt nicht nur die Länge der einzelnen Bereiche, sondern macht auch Aussagen über deren 
Inhalt und das Programm, das den Bereich angefordert hat. Außerdem werden sämtliche im 
Profibuch dokumentierten Systemvariablen und Strukturen angezeigt. 

Beim Starten installiert sich SysMon in den Systemvektoren und untersucht den Speicher nach 
vorher geladenen Programmen. Wird SysMon dann über eine bestimmte Tastenkombination 
aktiviert, kann man alle folgenden Systemaufrufe dokumentieren. Da SysMon ziemlich viel 
Speicher benötigt (ca 200 KB) und somit auf Rechnern mit wenig Speicher nicht permanent 
geladen werden kann, ist er in der Lage, sich selbst wieder aus dem System zu entfernen. 

Durch diese Möglichkeiten eignet sich SysMon vorzüglich zum Debuggen von eigenen 
Programmen oder zur Analyse von fremden Programmen. Auch früher besonders schwer zu 
debuggende Probleme, wie die Kommunikation zwischen verschiedenen Prozessen, sind mit 
SysMon schnell und einfach zu bewerkstelligen. 

SysMon arbeitet auf allen Atari-Rechnern der ST-, STE- und T-Baureihe und unter allen 
bislang veröffentlichten TOS-Versionen. Da ein Monitor selber nicht Systemfunktionen, die 
er beobachtet, zur Ausgabe benutzen kann, werden eigene Funktionen benutzt. Diese 
unterstützen alle Standard-Auflösungen, wobei auch Anpassungen an einige zusätzliche 
Grafikkarten vorgenommen wurden. 

Es existiert eine Schnittstelle zum Maschinenspache-MonitorTempleMon, die es ermöglicht, 
die Analyse auch auf die Assembler-Ebene auszudehnen und einzelne Aufrufe schrittweise 
abzuarbeiten. SysMon kostet 149- DM zzgl. Porto und Verpackung. Er ist zu beziehen bei 

OverScan Gbr 
Säntisstraße 166 
D-W1000 Berlin 48 
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Das umfangreiche Manual erklärt die Benutzung und Möglichkeiten des SysMon und bietet 
neben einer Einführung in den Funktionsablauf des Atari-Betriebssystems und einer Anlei¬ 
tung zum “Auflösungsunabhängigen Programmieren” auch ein größeres Kapitel über Tips, 
Tricks und Fallstricke bei der Programmierung der Atari-Rechner. Für registrierte Nutzer der 
Versionen 1.0.x gibt es eine günstige Updatemöglichkeit. 


TempleMon 

TempleMon ist ein speicherresidentes Monitorprogramm, das Fehlermeldungen (Exceptions) 
der CPU abfängt, und die Möglichkeit der Betrachtung und Modifikation des CPU-Zustands 
zum Fehlerzeitpunkt bietet. Bei geeigneter Änderung kann oft das unterbrochene Programm 
fortgesetzt werden, um z. B. noch eine Sicherung des gerade bearbeiteten Dokumentes vor¬ 
zunehmen. Ferner ist auch das Disassemblieren von Speicherbereichen und das Tracen von 
Programmen vorgesehen. Bei der Verwendung von TempleMon sind Kenntnisse über Aufbau 
und Programmierung der CPU empfehlenswert. 

TempleMon ist ein “Public Domain”-Programm und kann über verschiedene Mailboxen oder 
PD-Vertriebe bezogen werden. Die Autoren Thomas Tempelmann und Johannes Hill bieten 
weiterhin die Möglichkeit an, sich als Anwender registrieren zu lassen. Dazu schicken Sie bitte 
DM 30 - mit ausreichend frankiertem (für einen Brief ca. 100g) und vollständig beschriftetem 
Rückumschlag Format C5 an 

Johannes Hill 
Alicenstraße 30 
D-W6100 Darmstadt 1. 

Sie bekommen dann ein Handbuch zurückgeschickt. Haben Sie zusätzlich noch eine forma¬ 
tierte Diskette beigelegt, dann gibt es auch noch die neueste Programmversion. 


Wega-Library 

Das “WEGA” Developer Toolkit ist eine C-Library, die Funktionen zur komfortbien Handha¬ 
bung von Dialogboxen (auch in Fenstern) enthält. Nähere Informationen gibt es beim Profi¬ 
buch-Autor 

Dietmar Rabich 

Koppelbusch 37 (bis 31.12.1991: Dövelingsweg 2) 

D-W4408 Dülmen 
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Anhang J: 

Die Hardware des ATARI STE 


Auf der Atari-Messe in Düsseldorf stellte Atari im September 1989 einen neuen Computer der 
ST-Serie vor. Er befindet sich im gleichen Gehäuse wie der “1040STF(M)” und fällt damit 
ebenfalls unter die Kategorie Tastaturcomputer. 

Als Produktbezeichnung hat Atari die Modellbezeichnung “STE” gewählt, was darauf hin¬ 
deuten soll, daß es sich hier im Prinzip um einen “normalen ST” handelt, der jedoch in einigen 
Punkten erweitert wurde (dafür das E in STE!). 

Bevor es um Details zu den einzelnen Erwei terungen geht, soll hier in Kurzfassung aufgeführt 
werden, was denn beim STE anders als bei seinen “Brüdern” ist (siehe hierzu auch das Block¬ 
schaltbild Abbildung 0.2 im Kapitel “Einführung” des Teils “Die Hardware des ST”). 


Die Erweiterungen in Kurzfassung 

- Leider nicht anders als bei den “normalen STs” (ausgenommen seien hier die MEGA 
STs) ist die Tastatur des STE! Sie ist die gleiche wie die der Vorgänger. 

Wesentliche Erweiterungen und Änderungen sind jedoch bei der Video-Hardware vorgenom¬ 
men worden: 

- Der BLITTER ist im STE serienmäßig vorhanden! 

- Für jede der drei Primärfarben Rot, Grün und Blau existieren in den 16 Farbregistem nun 
vier statt bisher drei Bits zur Farbauswahl. Damit stehen (ohne besondere Programmier¬ 
tricks) in der niedrigen Auflösung dann 16 Farben aus 2 (,M+4) = 2 12 = 4096 Farbtönen zur 
Verfügung! 

- Für GENLOCK-Anwendungen (Mischen von Videosignalen von z. B. Videokamera 
oder -Recorder mit dem ST-Videosignal) ist der STE von außen nun voll synchronisierbar. 

- Ein zusätzliches STB-Video-Base-Register für das Low-Byte der Anfangsadresse des 
Video-RAMs erlaubt nun die Positionierung des Bildschirmspeichers im RAM auf 
Word-Grenzen (bei den “normalen STs” fehlte das Register für das Low-Adreßby te, und 
somit konnte der Bildschirmspeicher im RAM immer nur an einer 256-Byte-Grenze 
beginnen!). Im STE ist damit nun vertikales Finescrolling möglich. 
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- Zur Unterstützung von horizontalem Finescrolling besitzt der STE ein eigenes HSCROLL- 
Register. 

Außerdem ist der STE nun “zugänglicher” geworden. 

- Zusätzlichzum vom STbekanntenMaus- und Joystickanschluß überdenTastaturprozessor 
hat Atari dem STE zwei neue Portanschlüsse mitgegeben. Über Adapter lassen sich daran 
bis zu vier weitere Joysticks anschließen. Außerdem kann an diese Ports ein Light-Pen 
bzw. eine Light-Gun für Spiele angeschlossen werden. Für Hardware-Bastler natürlich 
besonders interessant: Acht dieser Portleitungen an den neuen Joystickbuchsen lassen 
sich auch als Ausgangsports “mißbrauchen”! 

- Bisher gab es bei den STs nur digitale Ein- und Ausgänge. Beim STE stehen nun erstmals 
an den zwei neuen Portanschlüssen auch analoge Eingänge zur Verfügung, an die je zwei 
Paddies (Drehregler) angeschlossen werden können. 

Auch für die Ohren hat der STE einiges zu bieten: 

- Zur Tonerzeugung stehen zusätzlich zum ST-Soundchip (PSG) nun zwei PCM- 
Soundkanäle (Stereo-Sound möglich) mit je 8-Bit Auflösung und eigenen Ausgängen 
zur Verfügung. Die Sounddaten können im DMA-Betrieb abgespielt werden. 

Die Steuerung der Lautstärke, Balance und die Klangbeeinflussung der neuen Soundkanäle 
erfolgt über einen eigenen Chip. Dieser Chip wird über eine zusätzliche serielle Schnitt¬ 
stelle im STE, das sogenannte MICROWIRE™-Interface angesteuert. Die Datenübertra¬ 
gungsgeschwindigkeit auf dieser seriellen Schnittstelle beträgt 1 MBit/s! 

Um alle diese neuen Komponenten entsprechend ansteuem und einsetzen zu können, waren 

natürlich Änderungen am Betriebssystem erforderlich: 

- Die zusätzlichen Routinen belegen mehr ROM-Speicherplatz. Deshalb kommt man mit 
192 KByte ROM im STE nicht mehr aus. Der bisher benutzte Adreßraum für das TOS 
von $FC 0000 - $FE FFFF ist somit ebenfalls zu klein geworden! Das STE-TOS be¬ 
findet sich deshalb in zwei 1 MBit-EPROMS ab Adresse $E0 0000 und reicht bis 
$E3 FFFF! 


Zusätzliche Verbindungen zur Außenwelt 

Wie ja schon zuvor erwähnt, besitzt der STE einige zusätzliche Anschlußmöglichkeiten. Als 
augenfälligste Ergänzungen bei den neu hinzugekommenen Anschlüssen sind die zwei zu¬ 
sätzlichen Buchsen für Joystick/Paddles/Light-Gun bzw. Light-Pen zu nennen. 


Anhang J: Die Hardware des ATARI STE 


1287 



Abb. J.l: Schaltung der zusätzlichen Joystickports im STE 
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Zwei Buchsen für vier Joysticks - und noch einiges mehr 

Nur drei zusätzliche Chips in der STE-Hardware erlauben auf einfache Weise den Anschluß 
von vier zusätzlichen Joysticks (auf die Paddies gehen wir später noch ein!). Dabei lassen sich 
an jede der beiden 15poligen Subminiatur-Buchsen zwei vollwertige Joysticks über einen ent¬ 
sprechenden Adapter anschließen. Die Pinbelegung der beiden Buchsen und die Anschaltung 
der Joysticks über die zusätzlichen Chips zeigt die Abbildung J. 1. 

Und nun zur Funktionsweise: 

Die Richtungskontakte der Joysticks und die Kontakte der Fire-Buttons müssen gegen Masse 
schließen, um eine Reaktion auszulösen. Wenn die Kontakte nicht geschlossen sind, liegen 
die Anschlüsse über Pull-up-Widerstände an +5V. 

Die Portanschlüsse sind auf die Eingänge derdrei Bus-Trciberbausteine V509/V510/V512 des 
Typs 74LS244 geführt. Dabei werden die Kontakte für die vier Fire-Buttons vom Bustreiber 
V509 “bedient”, während die Richtungskontakte der vier Joysticks an V510 und V512 auf¬ 
laufen. 

Die Bus-Treiberbausteine arbeiten nach folgendem einfachen Prinzip: Liegt am _1Q- bzw. 
_2Q-Anschluß ein High-Pegel, sind die Ausgänge IQ -1Q4 bzw. 2Q1-2Q4 im hochohmigen 
Zustand. 

Geht der _1Q- bzw. _2Q-Anschluß des Bustreibers auf Low, so wird der Logik-Pegel der 
Eingangsanschlüsse 1A1 - lA4bzw. 2A1 -2 A4 an den entsprechenden 1Q1 - 1Q4 bzw. 2Q1 
- 2Q4-Ausgängen präsentiert. In unserem Fall gelangen die Logikpegel der Joysticks also über 
die Bustreiber auf den Datenbus! 

Dabei werden die Richtungsinformationen von Joystick 0 (Joyport 0) und Joystick 2 (Joyport 
1) auf die unteren acht Datenleitungen des Datenbusses abgebildet. Die Joysticks 1 (Joyport 
0) und 3 (Joyport 1) legen die Richtungsinformationen auf den oberen acht Datenleitungen 
des 16 Bit-Datenbusses ab. 

Das “Einlesen” der Joystick-Richtungsinformation erfolgt also mit einem Low-Impuls auf den 
Leitungen XJOYRL und XJOYRH. Diese Leitungen kommen im STE vom MCU-Baustein, 
in dem die Funktionen von GLUE und MMU zusammengefaßt worden sind. Durch einen 
Word-Lesezugriff auf die Adresse $FF 9202 wird dieser Low-Impuls auf den Leitungen 
XJOYRL und XJOYRH erzeugt und somit der Zustand der Joystick-Richtungstasten direkt 
über die Bustreiber auf den Datenbus gegeben. Da die CPU ja gerade einen Lesezugriff 
durchführt, werden so die Richtungsinformationen der vier Joysticks mit einem Wordzugriff 
direkt eingelesen! 
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Das Einlesen der Fire-Button-Informationen erfolgt nach dem gleichen Schema. Jedoch muß 
dazu auf der XBUTTON-Leitung ein Low-Impuls erzeugt werden. Das geschieht durch 
entsprechende Dekodierung der Adreßleitungen der CPU durch den MCU-Baustein bei einem 
Word-Lesezugriff auf die Adresse $FF 9000. Die unteren vier Bits des Datenwords an Adresse 
$FF 9000 geben damit den Zustand der vier Fire-Buttons wieder. 

Somit ergeben sich im Adreßraum des STE zwei Adressen, an denen die Zustände der vier 
Joysticks direkt abgefragt werden können! 


Adresse: 

Bit-Nr. : 

Inhalt: 

SFF 92BB 

15 14 13 12 II IO 9 Ö 7 6 5 4 3 2 1 0 

1 t i .l M i t :il u.' 1 -1 Sl fTTTBl 

'-unbenutzt-'Button-Hr . 

Zustand der Fire-Buttons 
für Joysticks/Paddies 

(Log. 0=Button betätigt!) 

Adresse: 

Bit-Nr. ! 

Inhalt: 

SFF 92B2 

IS 14 13 12 1 1 10 g S 7 & 5 4 3 2 1 0 

RichtungsinfOrnationen 
der Joysticks 0-3 


v ..1- A - 1 .1-' s - i 

Stick 3 Stick 1 Stick 2 Stick 0 

CLog. 0 = Stick betätigt!) 


Abb. J.2: Die Adressen der neuen Joystickports 


Wie im Schaltungsauszug in Abbildung J. 1 dargestellt ist, wird vom Joyport 1 die Fire-Butlon- 
Leitung des Joysticks 0 (Pin 6 der Buchse) noch zusätzlich über die XPEN-Leitung zur MCU 
geführt. Über diese Leitung gibt der Light-Pen bzw, die Light-Gun einen Low-Impuls ab, 
wenn der Elektronenstrahl beim Beschreiben der Bildschirmfläche jene Stelle erreicht, die 
vom Light-Pen/Light-Gun gerade abgetastet wird. 

Atari gibt für die Genauigkeit der abgetasteten Bildschirmposition bei Betrieb mit Light-Pen/ 
-Gun folgende Toleranzen an: 

- In vertikaler Richtung ist die Position auf ein Pixel genau. 

- In horizontaler Richtung ergeben sich je nach Betriebsart unterschiedliche Toleranzwerte: 


Modus 

Toleranz 

320 x 200 

4 Pixel 

640 x 200 

8 Pixel 

640 x 400 

16 Pixel 
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Diese Toleranzen gelten unabhängig von der Qualität des verwendeten Light-Pens/-Gun. 
Auch ein hochwertigerer Light-Pen wird die angegebenen Toleranzwerte nicht weiter drücken 
können. 

Die X- und Y-Position des Lightpens ist aus folgenden Registern mit einem Wordzugriff (als 
16 Bit Wert) zu “erfahren”: 


Adresse 

Label 

Inhalt 

$FF 9220 

XPEN 

X-Position des Lightpens 

$FF 9222 

YPEN 

Y-Position des Lightpens 


Dabei ist zu beachten, daß die Positionswerte im XPEN-Register in Pixel für den Lowres- 
Modus (320x200Pixel) geliefert werden. Umkorrekte Werte im Midres-Modus (640x200 Pixel) 
zu erhalten, ist der Wert im XPEN-Register um eine Bitposition nach links zu shiften. Bei 
Highres-Betrieb (640x400 Pixel) ist der XPEN-Wert um zwei Bits nach links zu shiften, um 
die korrekte Positionsangabe zu erhalten! 


Keine Einbahnstraße für Daten - Joystick-Ports als Ausgänge 

Bis jetzt war immer nur von drei der vier zusätzlichen Chips an den Joystickports des STE die 
Rede. Im Schaltungsauszug befindet sich jedoch noch ein weiterer Chip im Joystickinterface. 
Der Baustein V511 ist ein sogenanntes Oktal-Latch. 

Die Funktionsweise ist folgende: 

Mit der ansteigenden Flanke eines Signals am C-Anschluß werden die Logikpegel der 
Eingänge 1D - 8D in dem Baustein gespeichert. Bei Lo w-Pegel am _OE-Anschluß erscheinen 
die gespeicherten Informationen an den Ausgängen IQ - 8Q. Ist der _OE-Anschluß des 
Bausteins jedoch auf High-Pegel, so gehen alle Ausgänge IQ - 8Q in den hochohmigen 
Zustand. 

Im STE sind die acht Eingänge des Oktal-Latches an die acht niederwertigen Leitungen des 
Datenbusses angeschlossen, und die acht Ausgänge des Bausteins V511 führen an die 
Anschlüsse der Joysticks 0 (Joyport 0) und 2 (Joyport 1). Vom MCU-Baustein steuern die 
beiden Leitungen JOYWL und XJOYWE die Anschlüsse C und _OE des Latches nun so an, 
daß bei einem Schreibzugriff auf die Adresse $FF 9202 (Label JOYDIR) die unteren acht Bits 
der geschriebenen Information als Logikpegel an den Joystickanschlüssen 0 und 2 ausgegeben 
werden. Die Pegel bleiben so lange “stehen”, bis ein erneuter Schreibzugriff auf diese Adresse 
erfolgt oder bis auf Adresse $FF 9202 lesend zugegriffen wird! 



Anhang J: Die Hardware des ATARI STE 


1291 


Damit lassen sich also acht Bits an Informationen blitzschnell (so schnell die CPU kann) 
parallel ausgeben! 


Von Analog nach Digital - Paddies am STE 

Schon bei den 8-Bit-Ataris (Serie 800/800XL/130XE) war es möglich,nichtnur Schalterzustände 
von z. B. Joysticks abzufragen, sondern stufenlose Richtungs- oder sonstige Informationen an 
den Computer weiterzugeben. So lassen sich mit sogenannten Paddies, das sind Drehregler, 
stufenlos Richtungsinformationen o. ä. einstellen. Je weiter der Regler aufgedreht ist, desto 
höher ist derübermittelte Wert. Die Drehregler bestehen aus veränderbaren Drehwiderständen 
miteinem Widerstandswertvon>470kOhm (Atari-Paddies haben 680 kOhm-Drehwiderstände 
im Vollausschlag). Durch eine Elektronik werden diese analogen Widerstands werte der Dreh- 
regier in digitale Zahlenwerte umgewandelt. 

Im STE hat Atari wieder auf diese Steuerungsmöglichkeit zurückgegriffen und erlaubt den 
Anschluß von je zwei Paddies an jedem Joyport. Damit besteht sogar die Möglichkeit, soge¬ 
nannte analoge Joysticks zu verwenden, die statt Richtungskontakten über veränderbare Wi¬ 
derstände verfügen und so eine stufenlose Richtungsangabe erlauben! 

Wie der Schaltungsauszug in Abbildung M.3 zeigt, existiert für jeden der vier möglichen 
Paddleanschlüsse eine eigene Schaltung. Dabei handelt es sich um sogenannte monostabile 
Multivibratoren oder auch Monoflops. Im STE werden dazu sogenannte Timer-ICs vom 
Typ ”LM 556" verwendet, wobei je zwei Monoflops in einem IC-Gehäuse untergebracht 
sind. 

Monoflops haben die “Angewohnheit”, durch einen Impuls von ihrer Ruhelage (Ausgangspegel 
in unserem Fall auf Low) für eine bestimmte Zeit in die Arbeitslage (Ausgangspegel in 
unserem Fall dann High) “umgekippt” zu werden. Die Dauer, in der das Monoflop in der 
Arbeitslage “verharrt”, ist abhängig von einem Zeitglied, das aus einem Widerstand besteht, 
über den ein Kondensator aufgeladen wird. Erreicht die Ladespannung an dem Kondensator 
einen bestimmten Schwellwert, so wird das vom Monoflop-Baustein über einen Fühleranschluß 
“bemerkt”, und das Monoflop kippt zurück in seine Ruhelage. 

Die Dauer, in der das Monoflop in Arbeitslage bleibt, ist zum einen abhängig vom Kondensa¬ 
torwert (C T im Schaltungsauszug) und zum anderen vom Wert des Ladewiderstands. Beim 
STE wird der Ladewiderstand im Prinzip durch den Widerstand eines Paddies gebildet. Da 
dieser Widerstandswert veränderbar ist, läßt sich so auch die Zeitdauer der Arbeitslage des 
Monoflops direkt beeinflussen. Das Prinzip der Umwandlung von Widerstandswerten (der 
Paddies) in im STE verwendbare Zahlenwerte ist nun folgendes (siehe auch den Schaltungs¬ 
auszug in Abbildung J.3): 



1292 


ATARI Profibuch 



Abb. J.3: Einbindung der Paddies beim STE 

Für jeden Paddle existiert ein Zähler in der STE-MCU. In regelmäßigen Abständen (ca. alle 
0,52 ms) werden alle vier Zähler auf Null gesetzt und gleichzeitig die vier Monoflops mit 
einem Impuls über die XPADRST-Leitung in Arbeitslage “gekippt”. Die vier Zähler werden 
in einem bestimmten Takt weitergezählt (ca. 500 KHz im STE). Die Monoflops kippen je nach 
Widerstandswert der Paddies nach gewisser Zeit wieder in ihren Ruhezustand zurück und 
halten durch diesen Signal Wechsel an ihren Ausgängen (Leitungen XPADOX - XPAD1Y im 
Schaltplanauszug) “ihren” Zähler in der MCU an. 

Der so gewonnene Zählerstand ist damit direkt abhängig vom eingestellten Widerstandswert 
des Paddies und damit von dessen Position! So setzt man analoge Widerstandswerte in Zahlen¬ 
werte um. Dievier Paddle-Zähler-Register sind unter denfolgenden Adressen im Speicherraum 
des STE abfragbar: 


Adresse 

Label 

Inhalt 

$FF 9210 

PADDLO 

Position des Paddle 0 

$FF 9212 

PADDL1 

Position des Paddle 1 

$FF 9214 

PADDL2 

Position des Paddle 2 

$FF 9216 

PADDL3 

Position des Paddle 3 
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Die Register sind zwar 16 Bit breit. Es ist jedoch nur das Low-By te signifikant (es reicht also 
aus, das entsprechende Low-By te zu lesen!). Damit ergeben sich mögliche Paddle-Werte 
zwischen 0 und 255, wobei aber Werte über 200 nur mit Drehwiderständen mit einem maxi¬ 
malen Endwert von ca. 1 MOhm erreicht werden. 

Mit nachfolgender Faustformel kann für einen gegebenen Paddle-Widerstandswert (in der 
Formel mit R p bezeichnet und in kOhm einzusetzen) der entsprechende Paddle-Registerwert 
berechnet werden: 


394 

RegWert = - [ R p in kOhm! ] 

1 + 1000/R p 

Für die Fire-Buttons der Paddies werden die Fire-Button-Anschlüsse der Joysticks verwendet 
und können somit im Register JOYBUTT an Adresse $FF 9200 abgefragt werden. Nachfol¬ 
gend noch ein Verdrahtungsvorschlag für die Adaption von zwei handelsüblichen Joysticks 
mit 9poligen Anschlußbuchsen an einen STE-Joyport: 



Abb. J.4: Adapter zum Anschluß von Joysticks und Paddies an die neuen STE-Joystickports 
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Wenn die gestrichelten Verbindungen ebenfalls eingelegt werden, so lassen sich an einem der 
beiden 9poligen Anschlüsse des Adapters zwei Paddies anschließen. 


Gutes für die Ohren - Sound in neuer Qualität 

Gegenüber den eher eingeschränkten Möglichkeiten der Sounderzeugung mit Hilfe des PSG 
im “normalen ST” hat sich beim STE doch einiges getan. So besitzt der STE jetzt zwei Sound¬ 
kanäle mit je 8 Bit Auflösung, herausgeführt auf entsprechende Cinch-Buchsen zum An¬ 
schluß an handelsübliche Verstärker! 

8-Bit-Auflösung heißt dabei nichts anderes, als daß sich die Amplitude (der Ausgangswert) 
eines beliebigen Tonsignals in maximal 256 Stufen unterteilen und damit nachbilden läßt. Je¬ 
des Byte mit seinen 8 Bit stellt dabei einen sogenannten Sample dar, also einen Wert, den das 
Ausgangssignal zu einem bestimmten Zeitpunkt annimmt. Dabei ist der 8-B it-Wert als vorzei¬ 
chenbehaftete Zahl zu betrachten. 

$80 = -128 = maximale negative Amplitude 

$00 =0 = minimale Amplitude (Ruhestellung) 

$7F = +127 = maximale positive Amplitude 

Zur Tonerzeugung werden diese Samples nacheinander zum Abspielen an einen Digital/ 
Analog-Wandler (D/A-Wandler) ausgegeben, der diese in entsprechende Spannungswerte 
umwandelt. Nach entsprechender Aufbereitung (Filterung) steht dann das Signal an den 
Ausgangsanschlüssen zur Verfügung. 

Messungen im mir zur Verfügung stehenden STE ergaben jedoch, daß sich nicht der komplette 
8-Bit-Bereich auflösen läßt. Zwar soll der komplette Spannungsbereich zwischen -5V..+5V 
(Betriebsspannungen der D/A-Wandler) in 256 Stufen dargestellt werden können (je Stufe 
also ein Spannungshub von ca. 39mV). Die eingebauten D/A-Wandler hatten jedoch Pro¬ 
bleme, Samples mit Werten > 1801 in entsprechende Spannungswerte umzusetzen. Man sollte 
sich also, um Verzerrungen zu vermeiden, mit den Samplewerten im Bereich zwischen -80 
und +80 bewegen. 

Aus der Aneinanderreihung vieler dieser Samples läßt sich also ein beliebiges Tonsignal 
“zusammenbauen”. Die Ausgabe dieser im Speicher als 8 Bit-Werte abgelegten Samples an 
die D/A-Wandler kann mit vier verschiedenen Geschwindigkeiten erfolgen. Im STE stehen 
die Samplefrequenzen 6,258 kHz, 12,517 kHz, 25,033 kHz und 50,066 kHz zur Verfügung. 

Mit der niedrigsten Sampleffequenz werden also 6258 Samples pro Sekunde abgespielt! Oder 
anders ausgedrückt: Für eine Sekunde Sound sind 6258 Samples (= Bytes) erforderlich! 
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Abb. J.S: Aus Samples wird ein Tonsignal 
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Die Qualität des Sounds hängt wesentlich von der Samplefrequenz ab. So gilt die Faustregel, 
daß die Samplefrequenz mindestens doppelt so groß wie die höchste im Sound vorkommende 
Tonfrequenz sein soll. Um also auch hohe Signalfrequenzen im Sound realisieren zu können, 
sind entsprechend hohe Sampleffequenzen erforderlich. Für das menschliche Hörvermögen 
wird Musik in hoher Wiedergabequalität empfunden, wenn der Frequenzbereich zwischen ca. 
20 Hz und 20 kHz möglichst unverfälscht wiedergegeben wird. Dazu sind also bei digitaler 
Signalverarbeitung Samplefrequenzen > 40kHz erforderlich. In der professionellen Technik 
arbeitet man deshalb mit Sampleraten von ca. 44 kHz, wobei jeder Sample als 16 Bit-Wert 
vorliegt (Signalwerte in max. 65536 Stufen darstellbar)! 


Musik “von ganz alleine” - DMA auch für Sounddaten 

Um nun die einzelnen Samplewerte nicht Byte für Byte durch die CPU an die D/A-Wandler 
ausgeben zu müssen, bedient sich der STE zum Abspielen ganzer Blöcke von Samples (auch 
als Frame bezeichnet) der DMA-Technik. Beim STE wird dazu im HB lank-Interrupt jeweils 
ein Word (also zwei Samples) durch das im STE-Shifter mitintegrierte Sound-DMA-Modul 
an die D/A-Wandler ausgegeben. Dabei kann in zwei Modi gearbeitet werden: 

Stereo-Modus: Von dem vom Sound-DMA-Modul aus dem Speicher geholten Word 

wird das High-Byte als Samplewert für den linken Tonkanal (D/A- 
Wandler) verwendet und das Low-Byte für den rechten Kanal (D/A- 
Wandler). 

Mono-Modus: Ein Word enthält zwei Samplewerte, die der Reihe nach (erst High- 

Byte, dann Low-Byte) an beide D/A-Wandler gleichzeitig ausgegeben 
werden. Somit steht an beiden Soundausgängen das gleiche Signal zur 
Verfügung. 

Um also einen Frame (eine Giuppe von Samples) abzuspielen, muß das Sound-DMA-Modul 
“wissen”, wo ein Frame beginnt (Anfangsadresse) und wo dieser endet (Endadresse). Des 
weiteren läßt sich bei der Programmierung des Sound-DMA-Moduls festlegen, mit welcher 
Geschwindigkeit die Samples ausgegeben werden sollen (Samplefrequenz). Samples lassen 
sich außerdem mehr als einmal abspielen. Das Sound-DMA-Modul läßt sich dazu auf 
Dauerbetrieb einstellen und spielt so den Frame immer wieder von neuem ab. 

Da vom Sound-DMA-Modul immer Words aus dem Speicher gelesen und zur D/A-Wandlung 
gegeben werden, läßt sich immer nur eine gerade Anzahl von Samples pro Frame abspielen 
(auch bei Mono-Mode!). Entsprechend ist das Low-Bit der Frame-Start- und Frame-End- 
Adresse in den entsprechenden DM A-Registem immer Null! Die in der folgenden Tabelle mit 
versehenen Voreinstellungen sind nach Einschalten des STE (Reset) gültig! 
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Adresse 

Label 

R/W 

Bits 

Bedeutung 

$FF 8900 

RAV 


- RE 

Sound-DMA-Control-Reg. 

sndmactl 








00 

DMA-Sound aus (*) 




01 

DMA-Sound ein 




11 

DMA-Sound ein, Frame 





ständig wiederholen 

$FF 8902 

RAV 

- 00HH HHHH 

Frame-Start-Adresse 

sndbashi 




(High-Byte) 

$FF 8904 

RAV 

--MMMM MMMM 

Frame-Start-Adresse 

sndbasmi 




(Middle-Byte) 

$FF 8906 

RAV 


Frame-Start-Adresse 

sndbaslo 




(Low-Byte) 

$FF 8908 

R 

- 00HH HHHH 

Frame-Adress-Counter 

sndadrhi 




(High-Byte) 

$FF 890A 

R 

--MMMM MMMM 

Frame-Adress-Counter 

sndadrmi 

R 



(Middle-Byte) 

$FF 890C 

R 

- LLLL LLLL 

Frame-Adress-Counter 

sndadrlo 




(Low-Byte) 

$FF 890E 

RAV 

- OOHH HHHH 

Frame-End-Adresse 

sndendhi 




(High-Byte) 

$FF 8910 

RAV 

--jyüyjyljyl JyJJyJJyJyl 

Frame-End-Adresse 

sndendmi 




(Middle-Byte) 

$FF 8912 

RAV 

- LL LL LLLL 

Frame-End-Adresse 

sndendlo 




(Low-Byte) 

$FF 8920 

RAV 

- MO00 OORR 

Sound-Mode-Control 

sndmode 



II 





00 

6258 Hz Samplerate (*) 




01 

12517 Hz Samplerate 




10 

25033 Hz Samplerate 




11 

50066 Hz Samplerate 



C 

) 

Stereo-Modus (*) 



3 


Mono-Modus 
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Wie ja schon vom DMA-Baustein des ST bekannt, kann man auch hier wieder nicht mittels 
Langwort-Zugriff direkt die Start- und End-Adressen setzen. Man muß auf Assemblerebene 
entweder in einem Datenregister die Adressen “zurechtschieben” und dann, schön der Reihe 
nach, Low-, Middle- und High-Byte der Frameadressen im entsprechenden Sound-DMA- 
Register setzen. 

START: 

move.l #fStart,dO ; Frame-Startadresse -> DO. 

move.b dO,sndbaslo ; Low-Byte paßt, also einsetzen. 

ror.l #8,d0 ; Jetzt Mid-Byte passend schieben, 

move.b dO,sndbasmi ; Middle-Byte wegbringen. 

ror.l #8,d0 ; Jetzt High-Byte passend schieben, 

move.b dO,sndbashi ; Und ab ins Register damit. 

Diese Version hat den Nachteil, daß der Adreßwert in einem Datenregister (z. B. DO) stehen 
muß und nach den Verschiebungen nicht mehr in seiner ursprünglichen Form vorliegt. Durch 
eine weitere Verschiebung um 8 Bits nach rechts (“ror.l #8,d0”) ist der Adreßwert zwar wieder 
korrekt in DO enthalten, aber das kostet natürlich auch alles CPU-Zeit! 

Die nachfolgende Version benutzt den Stack für das “Aufbröseln” der Adressen in regi¬ 
stergerechte Form. 

START: 

pea fstart,-(sp) ; Frame-Start-Adr. auf Stack, 

tst.l (sp) + ; Stackptr. wieder korrigieren, 

move.b -3(sp),sndbashi ; Nun die Bytes der Frame-Start- 

move.b -2 (sp),sndbasmi ; Adresse wie sie benötigt werden 

move.b -1(sp),sndbaslo ; vom Stack holen und wegbringen! 

Nachdem die Anfangs- und Endadresse auf die eine oder andere Weise dem Sound-DMA- 
Modul mitgeteilt worden sind, wird im Modus-Kontrollregister (“sndmode”, Adr. $FF 8920) 
die gewünschte Samplefrequenz und die Betriebsweise (Stereo/Mono) gewählt. 

Nach Setzen von Bit 0 im Sound-DMA-Control-Register (“sndmactl”, Adr. $FF 8900) wird 
der Frame abgespielt. Ist Bit 1 im Sound-DMA-Control-Register ebenfalls gesetzt, wird der 
Frame ständig wiederholt. Eine Null im Sound-DMA-Control-Register stoppt den DMA- 
Sound sofort. 

Wer wissen will, welcher Sample als nächster gespielt wird, kann jederzeit die drei Sound- 
Adress-Register auslesen. Sie bilden zusammen den Zeiger auf das nächste Sample-Word. 
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Soundsteuerung mit und ohne Timer-A-Interrupts 

Um bei der DMA-Soundkontrolle flexibel zu sein, hat Atari beim STE ein wenig zusätzliche 
Hardware spendiert. 

Die Register für Frame-Start-Adresse und Frame-End-Adresse sind gebuffert. Das bedeutet, 
daß eine dort hineingeschriebene Adresse zunächst zwischengespeichert wird. “Benutzt” wird 
diese Adresse erst dann (die Adreßwerte werden in die entsprechenden Arbeitsregister trans¬ 
portiert), wenn der momentan gespielte Frame beendet wurde. In der Praxis kann man deshalb 
schon während des Abspielens eines Frames die Adressen des nächsten Frames eintragen. Der 
nächste Frame wird dann “nahtlos” an den vorigen “angehängt”! 

Mit der Information, wann ein Frame zu Ende ist, besteht die Möglichkeit, eine ganze Serie 
von Frames hintereinander zu ketten! Dazu liefert das DMA-Sound-Modul ein Signal überden 
augenblicklichen “Stand der Dinge”. Von Pin 105 der MCU über einen Inverter (74LS04) 
geführt, steht ein Signal (“XSINT”) zur Verfügung, das auf High liegt, wenn gerade ein Frame 
gespielt wird (siehe auch Abbildung J.6). 


MCU 


Uon Pin 3 der_ 
Monitorbuchse 

<B<?i Low an Pin ^ 
wird an Pin 4 ein 
ext. syste-ntakt 
eingespeist|J 


Uon Pin 4 der. 
Monitorbuchse 

«Monochrom-Deteet~ 
Sisnai oder Ex*. 
Syste-rttakt Fuer 
Genlock-ftnwcndg .% 


74S2371 




+5V + 


, 32MHz-Takt von 
TaktosziUator 


Mastertakt fuer 
das gesamte System 

fftn P.S3 des SHIFTERS) 


I74LSB4I 

J 

□ 

ks 

i 

r 


. 2MHz-Takt des DMft~ 
Sound-Systems 


I74L51&41 


<E L clr 


ID 


Ui- 


I74LS86I 


=1 


I/O-POM 7 


MFP 


I/O-Port 7 


Abb. J-6: Signallauf des XSINT-Signals im STE 
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MitEinlesen des letzten Words eines Frames geht das Signal auf Low und erst wieder auf High, 
wenn wieder ein Frame begonnen wird. Das geschieht auch, wenn das Sound-DMA-Modul 
auf “Dauerbetrieb” (ständiges Abspielen eines Frames) eingestellt ist. Da das Sound-DMA- 
Modul einen 4-Word-FIFO-Buffer besitzt, geht das Signal XSINT also bereits vier Words 
(= acht Samples) vor Frameende auf log. 0! 

Beim STE wird das XSINT-Signal sinnvollerweise (nach einer Aufbereitung durch ein mit 
2MHz getaktetes 8fach-Schieberegister des Typs 74LS164) auf den Eingang des Timers A 
vom MFP geführt und kann damit Interrupts auslösen, wenn jeweils ein oder mehrere Frames 
beendet wurden (je nach Einstellung des Timers A). 

Um Impulse am Eingang des Timers A erfassen zu können, muß im Aktive-Edge-Register, 
Bit 4 (AER, Adresse $FF FA03) des MFP eingestellt werden, auf welche Flanke der XSINT- 
Impulse der Eingang des Timers A reagieren soll. 

Mit diesem AER-Bit wird aber auch eingestellt, auf welche Flanke der Interrupt am Port 104 
des MFP (Interruptsignal von Midi- und Tastatur-ACIA) auslöst. Atari hat das XSINT-Signal 
deshalb so ausgelegt, daß bei beiden Signalen jeweils auf fallende Flanken reagiert wird (Bit 4 
im AER auf 0!). 

Man braucht sich deshalb um die Programmierung des AER-Bit 4 nicht mehr zu kümmern, 
denn das wird vom Betriebssystem zur Bedienung der Midi- und Tastatur-Interrupts schon 
richtig voreingestellt! 

Um nun also verschiedene Frames direkt hintereinander abspielen und evtl, einzelne Frames 
unterschiedlich oft wiederholen zu können, wäre die folgende Vorgehensweise angebracht: 

Beispiel: Frame A (eine Sinusschwingung) soll lOOmal gespielt werden, direkt anschlie¬ 
ßend folgt 150mal eine Dreieckschwingung und zum Schluß noch 250mal der 
Frame C für eine Rechteckschwingung. 

1. Start- und Endadressen für Frame A im Sound-DMA-Modul setzen. 

2. Timer-A auf Ereigniszählung programmieren (es sollen die XSINT-Impulse (sprich: 
Frames) gezählt werden). Interruptvektor für Timer-A auf eigene Interruptroutine 
setzen. Timer-A mit der Zahl der Framewiederholungen -1 laden. 

3. Samplerate und Modus (Stereo oder Mono) im Sound-Mode-Register einstellen. Bit 0 
und 1 im Sound-DMA-Control-Register (sndmactl, Adresse $FF 8900) setzen. Frame 1 
wird gespielt, Wiederholbetrieb ist eingeschaltet. [Am Ende der 99sten Wiederholung 
von Frame A löst der Timer-A einen Interrupt aus!] 
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4. In der Interruptroutine Adressen für Frame B setzen. Ebenso die Anzahl der Wiederho¬ 
lungen für Frame B (150) in Timer-A einstellen. Interruptroutine verlassen. 

[Sobald die letzte Wiederholung von Frame A beendet ist, wird der zweite Frame 
begonnen (Bufferung!), und der Timer-A zählt von 150 auf 149. Am Ende der 149sten 
Wiederholung von Frame B wird wieder ein Interrupt ausgelöst.] 

5. In der Interruptroutine Adressen für Frame C setzen. Ebenso die Anzahl der Wiederho¬ 
lungen für Frame C (250) in Timer-A einstellen. Interruptroutine verlassen. 

[Am Ende der letzten Wiederholung von Frame B wird der dritte Frame begonnen, und 
der Timer-A zählt von 250 auf 249. Zum Ende der 249sten Wiederholung von Frame C 
wird wieder ein Interrupt ausgelöst.] 

6. Im Interrupt Bit 1 des Sound-DMA-Control-Registers zurücksetzen. Damit ist die 
ständige Wiederholung eines Frames ausgeschaltet, und der letzte Frame wird noch zu 
Ende gespielt, dann hält das Sound-DMA-Modul an. Timer-A wird gestoppt, und die 
Timer-A-Interrupts werden disabled und maskiert. Das war’s! 

Nachfolgend ist ein Beispiellisting für den gerade beschriebenen Fall dargestellt. 


; Definition der verwendeten Adressen und Konstanten 


sndmactl 

equ 

$FF8900 

r 

Sound-DMA-Control-Register 

sndbashi 

equ 

$FF8903 

} 

Frame-Start-Address (High-Byte) 

sndbasmi 

equ 

$FF8905 

r 

Frame-Start-Address (Middle-Byte) 

sndbaslo 

equ 

$FF8907 

r 

Frame-Start-Address (Low-Byte) 

sndendhi 

equ 

$FF890F 

r 

Frame-End-Address (High-Byte) 

sndendmi 

equ 

$FF8911 

r 

Frame-End-Address (Middle-Byte) 

sndendlo 

equ 

$FF8913 

r 

Frame-End-Address (Low-Byte) 

sndmode 

equ 

$FF8920 

r 

Sound-DMA-Mode-Register 

MWDATA 

equ 

$FF8922 

r 

MICROWIRE-Data-Register 

MWMASK 

equ 

$FF8924 

t 

MICROWIRE-Mask-Register 

iera 

equ 

$FFFA07 

t 

Interrupt-Enable-Register A 

isra 

equ 

$FFFA0F 

t 

Interrupt-in-Service-Register A 

imra 

equ 

$FFFA13 

r 

Interrupt-Mask-Register A 

tadr 

equ 

$FFFA1F 

t 

Timer-A-Data-Register 

tacr 

equ 

$FFFA19 

r 

Timer-A-Control-Register 
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; Beispielprogramm für die Programmierung des STE-DMA-Sounds unter 
; Ausnutzung der Frame-Ende-Signalisierung (Signal XSINT) durch das 
; Sound-DMA-Modul mit auf Ereigniszählung programmiertem Timer-A. 

; (Das Programm muß im Supervisor-Modus ausgeführt werden!) 

Start: 


lea 

FRMDAT,a2 

;Ab FRMDAT steht eine Tabelle mit Zeigern 

move.1 

(a2)+,aö 

; auf Frame-Start/End-Adressen und Werten 

move.1 

(a2)+,al 

; für die Wiederholzahl der einzelnen 
; Frames. 

bsr 

setfram,e 

; Frameadressen setzen. 

move.w 

(a2)+,d0 

; Timer-A-Wert nach Register DO holen. 

subi.w 

#l,d0 

; Passend machen. 

move.1 

a2,pointer 

; Zeiger für nächstes Mal verwahren. 


; Timer-A wird jetzt auf Ereigniszählung programmiert. Außerdem 
; wird der zugehörige Timer-A-Interruptvektor auf die Routine 
; "t_a_int" umgeleitet. 

; Timer-A wird mit der Anzahl der Wiederholungen-1 für den ersten 
; Frame geladen. Nach entsprechend häufigem Wiederholen des Frames 
; A wird der Timer-A einen Interrupt auslösen, und die t_a_int- 
; Routine tritt in Aktion. 

pea t_a_int ; Zeiger auf Timer-A-Interruptroutine. 

move.w d0,-(sp) ; Wert für Timer-A-Data-Register. 

move.w #$8,-(sp) ; Wert f. T-A-Ctrl-Register 

(Ereigniszähl.!). 

clr.w -(sp) ; Timer 0 (= Timer-A) ist gemeint, 

move.w #31,-(sp) ; Xbios-Aufruf Nr. 31 (= Xbtimer) 

trap #14 

lea 12(sp),sp ; Stack korrigieren. 

; MFP-Interrupt #13 (Timer-A-Interrupt) wird freigegeben. 

move.w #13,-(sp) ; Interrupt #13 des MFP einschalten, 

move.w #27,-(sp) ; Xbios-Aufruf Nr. 27 (= Jenabint) 

trap #14 

addq.l #4,sp ; Stack korrigieren. 
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; Sound-DMA-Modul einstellen 

move.w #$80,sndmode ; Mono-Modus mit 6258Hz Samplerate 

; einstellen. 

move.w #3,sndmactl ; Bis auf ewig abspielen! 

; Über MICROWIRE-Interface den Volume/Tone-Control-Chip vor- 
; einstellen. 

move.w #$7ff,MWMASK ; MICROWIRE-Mask-Register 

; einstellen. 

move.w #%10011101000,d0 ; Lautstärke des LMC1992 auf 

; Maximum! 

bsr mw_write ; Befehl ü. MICROWIRE-Interf. ausgeb. 

the_end: 
rts 


; Interruptroutine, die vom Sound-DMA-Modul am Ende eines Frames 
; jeweils aufgerufen wird. Sie sorgt dafür, daß das Sound-DMA-Modul 
; immer mit den nächsten Framedaten nachgeladen wird. Außerdem wird 
; der Timer-A jeweils mit der Anzahl der Wiederholungen für den 
; nächsten Frame versehen. Wenn der letzte Eintrag in der Tabelle 
; ab FRMDAT abgearbeitet ist und der Interrupt zu Beginn der letz- 
; ten Wiederholung des letzten Frames auftritt, wird das Sound-DMA- 
; Modul auf Einzelframe-Wiedergabe geschaltet (letzten Frame noch 
; zu Ende spielen und dann stoppen) und Timer-A "abgeschaltet"! 

t_a__int: 

movem.1 

move.1 
tst.l 
beq.s 
move.1 
move.l 
bsr 
move.w 
move.b 
move.1 
bra.s 


dO/aO-a2, -(sp) 


pointer,a2 
(a2) 

t_a_intl 
(a2) +, aO 
(a2) + , al 
setframe 
(a2)+,d0 
d0,tadr 
a2,pointer 
t a end 


Benutzte Register auf Stack 
; retten. 

; Zeiger auf Frame-Daten holen. 

; Tabelleneintrag testen. 

Letzte Wiederholung des letzten Frames? 
Nein! Aus Tabelle die nächsten 
Frame-Adressen holen. 

Und im DMA-Modul setzen. 

Dann neuen Wert für Timer-A holen. 

Und Timer-A entsprechend setzen. 

Neuen Zeiger für nächstes Mal merken. 
Zum Ende springen. 
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t_a_intl: 

move.b 
and.b 
and.b 
move.w 

t_a_end: 

move.b 
movem.1 
rte 


#0,tacr 
#$DF,iera 
#$DF, imra 
#1,sndmactl 


; Ja! Timer-A stoppen! 

; Timer-A-Int. des MFP disablen. 

; " des MFP maskieren. 

; Frame noch beenden und dann 
; Schluß! 


#$DF,isra 
(sp)+,d0/a0-a2 


MFP über Int.-Ende informieren! 
Registerinhalte restaurieren. 


; Unterprogramm zum Setzen der Start- und Endadresse des abzuspie- 
; lenden Frames. 


r 

Parameter: 

A0 = Startadresse des Frames 

r 


Al = Endadresse des Frames 

/ 

Benutzte Reg.: Keine 


t 

setframe: 




move.1 

aO, - (sp) 

Startadresse des Frames in 


tst.l 

(sp) + 

die Frame-Start-Address-Register 


move.b 

-3(sp),sndbashi ; 

schreiben. 


move.b 

-2(sp),sndbasmi 



move.b 

-1(sp),sndbaslo 



move.1 

al,-(sp) 

Endadresse des Frames in 


tst. 1 

(sp)+ ; 

die Frame-End-Address-Register 


move.b 

-3(sp),sndendhi ; 

schreiben. 


move.b 

-2(sp), sndendmi 



move.b 

-1(sp),sndendlo 



sfrmend: 

rts 


; Unterprogramm zum Schreiben über MICROWIRE-Interface 
; Parameter: DO = zu schreibende Daten 

; Benutzte Reg: Keine 

r 

mw write: 

cmp.w #$7ff,MWMASK ; Warten, bis letzter 

bne. s mw_write ; Schreibvorgang beendet ist. 
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move.w dO,MWDATA ; Nun aber raus mit den Daten! 

rts 


.data 
pointer: 

dc.l FRMDAT ; Zeiger auf die nächsten Framedaten. 

FRMDAT: 

dc.l FRAMEA,FRAMEB ; Adressen für ersten Frame + Timer-A- 

dc.w 100 ; Wert 

dc.l FRAMEB,FRAMEC ; Adressen für zweiten Frame + Timer-A- 

dc.w 150 ; Wert 

dc.l FRAMEC,FRMENDE ; Adressen für dritten Frame + Timer-A- 
dc.w 250 ; Wert 

dc.l 0 ; Null signalisiert das Tabellenende! 

FRAMEA: ; Daten für eine Sinusschwingung 

dc.b 0,14,27,40,51,61,69,75,79,80 
dc.b 79,75,69,61,51,40,27,14,0 
dc.b -14,-27,-40,-51,-61,-69,-75,-79,-80 
dc.b -79,-75,-69,-61,-51,-40,-27,-14 
FRAMEB: ; Daten für eine Dreieckschwingung 

dc.b 0,10,20,30,40,50,70,80 
dc.b 70,60,50,40,30,20,10,0 
dc.b -10,-20,-30,-40,-50, -60,-70, -80 
dc.b -70,-60,-50,-40,-30,-20,-10 
FRAMEC: ; Daten für eine Rechteckschwingung 

dc.b 80,80,80,80,80,80,80,80 
dc.b -80,-80,-80,-80,-80,-80,-80,-80 
FRMENDE: 

Um nun nicht unbedingt den letzten frei verfügbaren Timer für die DMA-Soundsteuerung 
benutzen zu müssen, hat Atari im STE das XSINT-Signal noch an anderer Stelle für Program¬ 
mierer verfügbar gemacht. 

So wird das Frame-Ende-Signal noch zusätzlich mit dem Monochrom-Detect-Signal der Mo¬ 
nitorbuchse über ein Exklusiv-Oder (EXOR) zusammengefaßt und dann auf den Port 107 des 
MFP geführt (siehe hierzu auch Abbildung J.6!). 
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Um dieses Signal jedoch benutzen zu können, muß man ein paar Gegebenheiten berücksich¬ 
tigen. 

1. Der Interrupt tritt an jedem Frame-Ende (eigentlich vier Sample-Words vor Frameende, 
wegen des FIFO-Buffers im Sound-DMA-Modul) auf, und nichtnach einer bestimmten 
Anzahl von Frame Wiederholungen. 

2. Die mittels eines Interrupts auswertbare Flanke, zu der das DMA-Modul von “Abspie¬ 
len” auf “Frameende” umschaltet, ist durch die EXOR-Verknüpfung mit dem Monochrom- 
detect-Signal abhängig vom verwendeten Monitor! Hat man einen Monochrom-Monitor 
angeschlossen, so ist der l->0-Flanken\vechsel für die Interruptauslösung zu program¬ 
mieren. Ist kein Monochrom-Monitor angeschlossen, so ist die 0->l-Flanke zu benutzen. 
Um nun zu ermitteln, welche Flanke für die Interruptauslösung im AER, Bit 7, denn nun 
zu verwenden ist, ist folgender Weg zu beschreiten: 

- Das Sound-DMA-Modul abschalten (0 ins Sound-DMA-Control-Register schrei¬ 
ben), dadurch ist das XSINT-Signal auf 0! Der Zustand des Ports 17 des MFP wird 
jetzt nur noch wegen der EXOR-Verknüpfung durch das Monochrom-Detect- 
Signal beeinflußt! 

- Port 17 des MFP auslesen. Wenn eine log. 1 gelesen wird, hat man es mit einem 
Color-Monitor zu tun, und das Bit 7 im AER des MFP ist für die Interruptauslösung 
auf 1 zu setzen. Wird an Port 17 eine log. 0 erkannt, ist ein Monochrom-Monitor 
angeschlossen, und Bit 7 im AER ist zur Interruptauslösung mittels des XSINT- 
Signals auf 0 zu setzen. 

Man kann also die Sound-DMA-Steuerung auch über diesen MFP-Port I7-Interrupt abwik- 
keln. Es steht halt nur kein Timer für das Zählen der Frames zur Verfügung; das muß man dann 
in der Interruptroutine schon selbst machen! 


Von Digital nach Analog - Der Weg des Tonsignals im STE 

Die Abbildung J.7 zeigt das Zusammenspiel des STE-DMA-Soundteils im Überblick. 

Es ist deutlich die Trennung in Linker und Rechter Kanal zu erkennen. Die vom SHIFTER 
im DMA-Betrieb aus dem RAM gelesenen Sound-Daten (Samples) gelangen als 8-Bit-Werte 
zunächst in ein 8-Bit D-Flip-Flop und werden dort “eingefroren”, bis der nächste Sample 
folgt! Das “Einfrieren” wird durch die Signale _LD (Daten für linken Kanal) und _RD (Daten 
für rechten Kanal) für jeden Kanal getrennt bewirkt. Bei Mono-Betrieb werden beide 8-Bit- 
Latches gleichzeitig (_LD und JRD sind synchron) bedient. 
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Abb. J.7: Das Zusammenspiel des STE-DMA-Soundteils 
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An den Ausgängen der 8-Bit-Latches steht also jeweils für die Dauer eines Samples eine 8- 
Bit-Information an. Diese wird durch die nachgeschalteten Digital/Analog-Wandler in einen 
entsprechenden Spannungswert umgesetzt. Der Ausgangswert wird hochohmig über einen 
Impedanzwandler (1 fach Verstärker mithohemEingangs- und niedrigem Ausgangs widerstand) 
abgegriffen und einem geschalteten Tiefpaßfilter zugeführt. Dieser geschaltete Tiefpaßfilter 
vierter Ordnung wird direkt durch die Samplefrequenz (Frameclock) gesteuert und läßt nur 
noch Frequenzen unterhalb 40% der Samplefrequenz durch! 

Anschließend gelangt das Signal über zwei lökHz-Tiefpässe zweiter Ordnung. Das bedeutet 
also, daß in einem DMA-Sound-Ausgangssignal nur Frequenzen bis zu max, 16kHz “vertre¬ 
ten” sein können. Alles was darüber liegt, wird ausgefiltert. Am Ausgang des zweiten 16kHz- 
Filters liegt das Signal dann zur Bearbeitung durch den Volume/Tone-Controller LMC1992 
bereit. Die Pegelbeeinflussung (Volume) und Balancesteuerung erfolgt erst im LMC1992. Für 
die Anhebung/Absenkung der Bässe bzw. Höhen kann der LMC1992 einen Teil des Signals 
(in den Bässen/Höhen angehoben oder abgesenkt) zwischen dem ersten und zweiten 16kHz- 
Tiefpaßfilter einkoppeln. 

An den Ausgängen des LMC 1992 wird das Tonsignal für den rechten und linken Kanal direkt 
abgegriffen und über einen Schutzwiderstand (gegen Kurzschlüsse am Ausgang) und einen 
Kondensator gleichspannungsfrei auf die Cinch-Buchsen geführt. 

Damit über den Lautsprecher eines angeschlossenen Monitors auch etwas zu hören ist, werden 
beide Kanäle über eine Mischstufe (bestehend aus zwei Verstärkerstufen und zwei Mischwi¬ 
derständen) zusammengefaßt. Von dort gelangt das Tonsignal (in Mono) an die Monitorbuchse 
und an den HF-Modulator. 

Um aber das Tonsignal vom “alten” Soundchip PSG nicht zu vergessen (woher sonst den 
“schönen” Tastaturklick nehmen), hat Atari dessen Audiosignal ebenfalls über den LMC 1992 
geführt. Zusammen mit einem von außen zuführbaren externen Tonsignal wird das PSG- 
Audiosignal ebenfalls einer Bearbeitung durch den LMC1992 unterworfen. 


Kontrolle über den Sound - 
Das MICROWIRE ™-Interface 

Für die Beeinflussung des vom Sound-DMA-Modul gelieferten Tonsignals hat Atari einen 
eigenen Chip von National Semiconductor eingesetzt. Mit diesem speziellen Chip ist es 
möglich, per Softwarekontrolle Einstellung der Lautstärke (Volume), Balance (zwischen den 
beiden Kanälen) vorzunehmen. Außerdem ist eine Bass-/Höhenregelung per Software reali¬ 
sierbar. 
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Da dieser Chip nicht speziell für den STE ausgelegt wurde, sondern auch in Geräten der 
Unterhaltungselektronik (z. B. Fernseher) Verwendung findet, wird für die Übergabe der 
Parameter wie z. B. Lautstärke, Balance usw, ein einfaches, serielles Bussystem verwendet. 

National Semiconductors spricht hierbei vom MICROWIRE < ™ ) -Bussystem. Sowohl der 
Volume/Tone-Controller Chip LMC1992 als auch der STE besitzen dafür ein eigenes 
MICROWIRE frM) -Interface. Im STE wurde das Interface mit im SHIFTER-Chip unterge¬ 
bracht! 


Noch eine serielle Schnittstelle im STE 

Wie bereits angesprochen, wird der Parameteraustausch (Lautstärke, Balance usw.) mit dem 
LMC1992 über einen seriellen Bus abgewickelt. Der Bus besteht nur aus drei Leitungen, 
wobei die MWD-Leitung (MICROWIRE (TM) -Data) zum Transport der eigentlichen Daten 
benutzt wird. 

Dabei ist der Datentransport nur in eine Richtung, nämlich zum LMC1992 hin, vorgesehen. 
Das _MWE-Signal (MICRO WIRE (TM) -Enable) geht so lange auf Low, wie Daten gesendet 
werden, und über die M WK-Leitung (MICRO WIRE <TM) -Clock) erfährt der Empfänger (in un¬ 
serem Fall der LMC1992), in welchem Takt die Daten übermittelt werden. DieDatenübertra- 
gungsgeschwindigkeit beträgt dabei im STE immerhin 1 MBit/s! 

Das Bussystem und Übertragungsprotokoll ist dabei sehr flexibel ausgelegt, so daß mehrere 
verschiedene MICROWIRE riM, -Devices angesprochen werden können. 

Jedes Device kann individuell vom Controller (STE) adressiert werden. Die Länge des zu 
übermittelnden Datenstroms ist dabei abhängig vom adressierten Device. Damit jedes Device 
“mitbekommt”, wann es gemeint ist und welche Daten übertragen werden, hat der serielle 
Bitstrom folgendes Format: 

Zunächst werden N-Adrßsbits (beim LMC1992 im STE sind das zwei Bits) zur Festlegung des 
gewünschten Devices gesendet. Darauf folgen eventuell einige “Don’t care”~Bits und dann 
die eigentlichen Datenbits. 

Für die Bedienung des seriellen Interfaces werden im STE-SHIFTER zwei 16-Bit-Schiebe- 
register benutzt. Dazu werden im MICROWIRE^-Data-Register die Bits für den Bitstrom 
(Adreß- und Datenbits) abgelegt (Bit 15 wird zuerst ausgegeben, Bit 0 zum Schluß), der über 
die MWD-Leitung ausgegeben werden soll. Das MICROWERE <TM) -Mask-Register bestimmt, 
welche Bits im MW-Data-Register gültige Bits sind (also Adreß- bzw. Datenbits) und welche 
als “Don’t care”-Bits fungieren. 
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Adresse 

Label 

RAV 

Bits 

Bedeutung 

$FF 8922 

RAV 

DDDD DDDD DDDD DDDD 

Adreß-/Datenbits zur 

MWDATA 



Ausgabe ü. MWD-Leitung 

$FF 8924 

RAV 

MMMM MMMM MMMM MMMM 

MICROWIRE frM) -Mask- 

MWMASK 



Register 


Um also an z. B. den LMC1992 des STE eine Information abzusetzen, sind im MWDATA- 
Register zunächst die Adreßbits korrekt zu setzen. Der LMC1992 im STE hat die Adresse #2 
entsprechend binär “10”. Danach folgen die zu sendenden Datenbits. Wollte man z. B. an den 
LMC1992 den Binärwert “11011” senden, so könnte das mit folgenden MWMASK- und 
MWDATA-Register-Einstellungen geschehen: 


<-Schieberichtung 


10 11 
1111 


011X XXXX XXXX <- MWDATA 
1110 0000 0000 <-MWMASK 


oder 


XXXX 10XX XXII 
0000 1100 0011 


0 1 1 X <-MWDATA 
1110 <- MWMASK 


oder 


XXXX 
0 0 0 0 


XXXX 
0 0 0 0 


X 1 0 1 
0 111 


10 11 
1111 


<- MWDATA 
<- MWMASK 


oder 


1 0 X X 
110 0 


XXXX 
0 0 0 0 


XXXI 
0 0 0 1 


10 11 
1111 


<- MWDATA 
<-MWMASK 


(X = Don’t care) 


Wie in den Beispielen zu sehen ist, kommt es also nur darauf an, daß Adreß- und Datenbits 
gleichzeitig im MWDATA-Register stehen und die zugehörigen Mask-Bits gesetzt sind. 
Adreßinformation und Daten dürfen durch mehrere Bitpositionen getrennt werden, können 
aber auch direkt hintereinander anschließen. 
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Bei der Bedienung der beiden Register und damit des MICROWIRE (TM> -Interfaces im STE 
ist zu beachten, daß zuerst das MWMASK-Register gesetzt wird. Denn sobald das MWDATA- 
Register beschrieben wurde, gehen die Informationen auf den Bus! 

Während der Registerinhalt auf den Bus ausgegeben wird, ist ein Beschreiben der MWMASK 
und MWD ATA-Register nicht möglich. Um also die nächste Ausgabe starten zu können, muß 
gewartet werden, bis die gerade laufende Ausgabe beendet ist. 

Die beiden Schieberegister werden zur Informationsausgabe dabei Bit für Bit nach links 
rotiert! Das bedeutet, daß nach insgesamt 16 Bit-Shifts (also bei 1 MBits/s Datenübertragungs¬ 
geschwindigkeit nach ca. 1 öpsec) die Register durch eine komplette Rotation des eingeschrie¬ 
benen Bitmusters wieder in Ausgangsposition angekommen sind! Das Auslesen der Register 
während der laufenden Ausgabe ist möglich und liefert jeweils eine “Momentaufnahme” über 
den Zustand der Schieberegister. 

Diese Eigenschaften kann man sich zunutze machen, indem man durch ständiges Auslesen 
des MWMASK-Registers nach Starten der Ausgabe den Zeitpunkt feststellt, wann das 
MWMASK-Register wieder im Ausgangszustand angelangt ist. Dann ist nämlich die letzte 
Ausgabe abgeschlossen, und der nächste Wert für das MWD ATA-Register kann eingebracht 
werden. 

Da man es im STE selten mit einem anderen Device als dem LMC1992 zu tun haben wird, 
kann man das MWMASK-Registernach dem erstmaligen Setzen der“ Valid”-Bits unverändert 
lassen. Alle weiteren Kommandos an den LMC1992 haben ja das gleiche Format bezüglich 
der Anordnung der “Valid”-Bits! Man braucht also nur das MWD ATA-Register mit neuen 
Werten zu versehen. 


Computer Controlled Volume/Tone - Der LMC 1992 

Beim LMC 1992 handelt es sich um einen relativ leistungsfähigen Baustein zur Kontrolle von 
Audiosignalen. Im STE werden die im folgenden dargestellten Einstellmöglichkeiten benutzt: 

LMC1992 Device Adresse: 10 Wnär 


Datenbits 

Befehl 

011 V V 

V V V V 

Lautstärke einstellen 

0 0 

0 0 0 0 

-80 dB (Einstellung in Schritten 

0 1 

10 0 0 

-40 dB (zu je 2 dB möglich!) 

1 0 

1 X X X 

0 dB = max. Lautstärke 
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Datenbits 





Befehl 

101 

X L 

L 

L 

L 

L 

Lautstärke linker Kanal (2 dB/Schritt) 


0 

0 

0 

0 

0 

-40 dB 


0 

1 

0 

1 

0 

-20 dB 


1 

0 

1 

X 

X 

0 dB 

100 

X R 

R 

R 

R 

R 

Lautstärke rechter Kanal (2 dB/Schritt) 


0 

0 

0 

0 

0 

-40 dB 


0 

0 

1 

0 

1 

-30 dB 


1 

0 

1 

X 

X 

0 dB 

010 

X X 

H 

H 

H 

H 

Höhenanhebung bei ca. 15kHz um 2 dB/Schritt 



0 

0 

0 

0 

-12 dB Absenkung 



0 

1 

1 

0 

0 db (Linear) 



1 

1 

0 

0 

+12 dB Anhebung 

001 

X X 

B 

B 

B 

B 

Baßanhebung bei ca, 50Hz um 2 dB/Schritt 



0 

0 

0 

0 

-12 dB Absenkung 



0 

1 

1 

0 

0 dB (Linear) 



1 

1 

0 

0 

+12 dB Anhebung 

000 

X X 

X 

X 

M 

M 

Mischen mit PSG-Soundsignal/Ext. Soundsignal 





0 

0 

PSG-Signal mit -12 dB Absenkung zumischen 





0 

1 

PSG-Signal 1:1 zumischen 





1 

0 

PSG-Signal nicht zumischen 





1 

1 

reserviert 


Alle Kommandos sind beim LMC1992 also neun Bits breit.Mit den jeweils zwei Bits (10 bMr ) 
für die LMC 1992-Adresse ergeben sich also immer insgesamt elf Bits, die über den Bus 
auszugeben sind. Setzt man die Adresse und Daten unmittelbar aneinander und rechtsbündig 
ins MWDATA-Register, so ist als Wert für das MWMASK-Register das Bitmuster $07FF zu 
wählen. MWMASK- und MWDATA-Register müßten dann also folgendermaßen aussehen: 

MWMASK 0000 0111 1111 1111 

MWDATA XXXX X10D DDDD DDDD 

I ! I 1 


9 Bits für 

LMC 1992-Kommando 
Die beiden Adreßbits 
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Um im STE den Volume/Tone-Control-Chip auf max. Lautstärke einzustellen, müßte also 
folgende Einstellung in den beiden Schieberegistern benutzt werden: 

MWMASK 0000 0111 1111 1111 

MWDATA XXXX X100 1110 1000 

Die Bedienung der MWMASK- und MWDATA-Register in einem Programm ist ebenfalls 
aus dem Beispiellisting ersichtlich. 


Mehr Kontrollmöglichkeiten für den Videoteil 

Atari hat dem STE noch einiges an zusätzlicher Hardware im Videoteil “spendiert”. Damit 
lassen sich vor allen Dingen in der Colorbetriebsart einige interessante Effekte realisieren. 
Hauptsächliche Anwendungen dieser zusätzlichen Effektmöglichkeiten dürften im Spiele¬ 
bereich zu finden sein. 

Aber auch für einen anderen Hobbybereich dürfte der STE nun interessanter werden. Bisher 
war es nur mit direkten Manipulationen in der ST-Hardware möglich, sogenannte GENLOCK- 
Anwendungen unter Einbeziehung von STs zu realisieren. Gedacht ist hierbei an das Mischen 
von ST-Videosignalen mit anderen Videosignalquellen (z. B. Videokamera), um so beispiels¬ 
weise Titelbild- oder Hintergrundgestaltung mittels Computer zu unterstützen. 

Um Videosignale unterschiedlicher Quellen zu mischen, ist es erforderlich, daß alle Signale 
zueinander synchron sind. Das bedeutet nichts anderes, als daß ein Videosignal als Mastersignal 
verwendet wird, auf welches sich alle anderen Videosignale einzustellen haben. Für den ST/ 
STE folgt daraus, daß nicht die intern erzeugten H- und V-Synchronisationssignale verwendet 
werden, sondern extern zugeführte Signale zu verwenden sind. Das war ja schon bei den STs 
möglich (Bit 0 im Sync-Mode-Register (Adr. $FF 820A) auf log. 1 setzen und an der Monitor¬ 
buchse HSync- und VSync-Signale einspeisen)! Aber damit war der Beginn des Bildinhalts 
in jeder Zeile immer noch vom internen ST-Takt abhängig und führte deshalb zu unerwünsch¬ 
tem “Zeilenreißen” (das Bild begann von Zeile zu Zeile mehr oder weniger stark waagerecht 
versetzt und erschien deshalb ausgefranst und unruhig). 

Im STE ist es jetzt möglich, auch einen externen Mastertakt als Systemtakt einzuspeisen, der 
von einer Mastersignalquelle abgeleitet wird. Diese Mastersignalquelle muß in der Lage sein, 
an alle zu mischenden Videosignalquellen die aus einem Mastertakt abgeleiteten HSync- und 
VSync-Signale zu liefern und dem STE einen Mastertakt von 32,084988 MHz (= PAL-An¬ 
wendungen; bei NTSC-Anwendungen soll der ext. Takt bei 32,215905 MHz liegen) zur Ver¬ 
fügung zu stellen. Damit läuft der STE also völlig synchron zur Mastersignalquelle, und das 
Zeilenreißen ist vorbei. 
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Wie kommt der Mastertakt nun in den STE hinein? Dafür hat Atari die Beschaltung der STE- 
Monitorbuchse gegenüber den STs etwas verändert. An Pin 3 der Monitorbuchse kann nicht 
länger das General-Purpose-Output-Signal (GPO-Signal) vom PSG-Port IOA 6 abgegriffen 
werden. Vielmehr wird jetzt durch das Anlegen einer log. 0 an diesem Anschluß der “Weg 
frei gemacht” für den ext. 32 MHz-Mastertakt. Dieser Mastertakt wird dann an Pin 4 der Moni¬ 
torbuchse eingespeist. Die Zusammenhänge zwischen diesen beiden Anschlüssen zeigt auch 
der Schaltungsauszug in Abbildung J.6. Bei High an Pin 3 arbeitet Pin 4 als Monochrom-De- 
tect-Eingang, und bei Low wird der Mastertakt an Pin 4 erwartet. 

Wichtig! Nicht während des laufenden Betriebs die Taktumschaltung mit Pin 3 vornehmen. 
Also immer bei ausgeschaltetem STE Pin 3 gegen Masse legen und ext. Mastertakt an Pin 4 
zuführen. 


Mehr Farben im Zugriff - Erweiterungen bei der Farbpalette 

Eine weitere Hardware-Änderung betrifft den SHIFTER. Genauer gesagt die Palette-Register, 
denen Atari im STE nun für jede der drei Primärfarben Rot, Grün und Blau 4 Bit (statt bisher 
3 Bit im ST) für die Verschlüsselung der Farbintensität zugedacht hat. Somit sind nun 
3 x 4 Bit zur Farbauswahl möglich, und man kann aus 2 4+4+4 = 2' 2 = 4096 Farben wählen. 
Dabei sind aber ohne Tricks gleichzeitig auch künftig nur 16 verschiedene Farben darstellbar 
(wegen der weiterhin nur 16 Farbpalette-Register)! 


15 

8 ? 

e 


SDIBB 







i 

nicht 


1 - 

benutzt 




Palette-Register iw STE 

Blau-Intensität CO..151 
Grün-Intensität CO..151 
Rot-Intensität CO..15) 


Abb. J.8: Palette-Register im STE 

Um mit dem STE trotz der erweiterten Farb-Palette möglichst kompatibel zu bleiben, ist die 
Gewichtung (Intensität), mit der die einzelnen Primärfarben im Gesamtsignal auftauchen, für 
die unteren 3 Bits jeder Primärfarbe beibehalten worden. Die Voreinstellung für ein giftiges 
Grün ist auf ST und STE mit dem gleichen Wert im entsprechenden Palette-Register möglich. 
Beim STE kann man dieses Grün durch das zusätzliche 4. Bit halt noch ein wenig “giftiger” 
machen. 
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Entsprechend den zusätzlichen Bits in den Palette-Registern, wurde natürlich der D/A-Wand- 
ler am SH1FTER-Ausgang um je ein Bit auf 4 Bit-Auflösung je Primärfarbe erweitert. 


FinescroIIing mit Hardware-Unterstützung 

Durch einige Hardware-Änderungen ist es mit dem STE jetzt einfacher möglich, Finescrolling 
(Bildverschiebungen im Pixel-Raster) sowohl in senkrechter als auch in waagerechter Rich¬ 
tung vorzunehmen. Dazu wurden zwei neue Register eingeführt und drei bereits bekannte 
Register des Videoteils in ihrer Funktion erweitert. 

Senkrechtes Finescrolling 

läßt sich einfach dadurch realisieren, daß man während der Dunkeltastung des Elektronenstrahls 
(im Vertical-Blank) die Anfangsadresse des Bildschirmspeichers um eine Bildschirmzeile 
(das sind in der Regel 80 Bytes) herauf- oder heruntersetzt. Dadurch ergibt sich der Eindruck, 
als wäre das gesamte Bild etwas nach unten bzw. nach oben verschoben worden. Natürlich 
muß man im Speicher schon etwas mehr als nur einen Bildschirminhalt zur Verfügung haben 
(z. B. mehrere komplette “Bildschirme” direkt hintereinander in den Speicher laden). “Oben” 
und “unten” vom gerade dargestellten Bildschirminhalt muß sich im Speicher ja ebenfalls 
sinnvolle Bildinformation befinden, die angezeigt wird, wenn nach oben oder unten gescrollt 
wird. 

Man kann sich das Ganze also so vorstellen, als würde man auf dem Monitor ein Fenster sehen, 
das in senkrechter Richtung über ein großes Bild (im Speicher) verschoben werden kann. 

Das Problem mit dem senkrechten Finescrolling im ST besteht darin, daß man den Anfang des 
Bildschirmspeichers mittels des Video-Base-Registers (Video-Base-Reg. High-Bytebei Adr. 
$FF 8201, Video-Base-Reg. Mid-Byte bei Adr. $FF 8203) nur in 256 Byte-Schritten verset¬ 
zen kann. Es “fehlt” ja im Video-Base-Register ein Registerplatz für das Low-Byte der An¬ 
fangsadresse des Bildschirmspeichers. 

Im STE hat man dieses Register zusätzlich “eingebaut”, so daß senkrechtes Finescrolling jetzt 
problemlos möglich ist. Der vollständige Registersatz für die Anfangsadresse der Bildschirm¬ 
adresse sieht damit im STE folgendermaßen aus: 


Adresse 

Label 

i 

R/W 

Bits 

Bedeutung 

$FF 8201 

R/W 

XXHH HHHH 

Video-Base-Register, High-Byte 

dbaseh 
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Adresse 

Label 

RAV 

Bits 

Bedeutung 

$FF 8203 
dbasel 

RAV 

MMMMMMMM 

Video-Base-Register, Medium-Byte 

$FF 820C 
dbaselow 

RAV 

LLLL LLL0 

Video-Base-Register, Low-Byte 


Diese drei Register bilden zusammen den Pointer auf den Anfang des Bildschirmspeichers. 
Durch das zusätzliche “dbaselow”-Register läßt sich die Anfangsadresse des Bildschirm¬ 
speichers im STE auf jede beliebige Word-Grenze im RAM legen. 

Diese Anfangsadresse kann jederzeit ausgelesen werden. Auch das Neusetzen der 
Bildschirmspeicher-Anfangsadresse kann jederzeit durchgeführt werden; Auswirkungen sind 
aber erst nach dem nächsten Vertical-Blank (also beim Neubeginn des nächsten Bildes) zu 
erwarten. Denn was im Moment dargestellt wird, ist von der Adresse im Video-Address- 
Counter abhängig, und dieser wird jedesmal zu Beginn eines neuen Bildes mit dem Wert im 
Video-Base-Register initialisiert! 

Nachfolgend ist ein einfaches Demoprogramm für senkrechtes Finescrolling im Monochrom- 
Modus aufgeführt. Es werden zwei “normale” Doodle-Bilder hintereinander in einen Buffer 
geladen. Die aktuelle Bildschirmspeicher-Basisadresse wird abgefragt und verwahrt. Danach 
wird die Basisadresse des Bildschirmspeichers auf den Anfang des Buffers mit den beiden 
Bildern gelegt. Anschließend wird schrittweise der sichtbare Bildschirmausschnitt durch 
ständiges Erhöhen der Bildschirmspeicher-Basisadresse um 80 Bytes (= eine Zeile) darüber 
“hinweggefahren”. Das ergibt den Effekt, als würde das Bild von unten nach oben durchrollen. 

Zum guten Schluß wird der Videocontroller wieder auf die alte Bildschirmbasisadresse 
zurückgesetzt. 

1000 ' Vertikales Finscrolling mit STE (Einfaches Demo im 
' Monochrom-Modus!) 

1010 ' 


1020 ' Es werden zwei Bilddateien im Doodle-Format eingeladen und 
1030 ' zu einem Großbild "hintereinander" kopiert. Dieses Großbild 
1040 ' wird dann per vertikalem Scrolling einmal von oben nach 
' unten "durchfahren"! 

1050 ' 


1060 ' 
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1070 MEMORYJBLOCK 00,64000,Buffer%L:' 

1080 BLOAD "BILD_1.DOO",Buffer%L:' 

1090 BLOAD "BILD_2.DOO",Buffer%L+32000 
1100 ' 

1110 XBIOS (Physbase%L,2 ):' 

1120 ' 

1130 XBIOS (,5,L -1,L Buffer%L,-l) 

1140 ' 

1150 FOR Ypos%L=0 TO 399:' 

1160 Scrnadr%L=Buffer%L+Ypos%L*80:' 

1170 XBIOS (,5,L -1,L Scrnadr%L,-1) 
1180 WAIT .01:' 

1190 NEXT Ypos%L 
1200 ' 

1210 XBIOS (,5,L -1,L Physbase%L,-1):' 
1220 FRE (Buffer%L):' 


Platz für zwei 
".DOO"-Bilder 
Bilder einladen. 


Alte Bildschirm¬ 
adresse merken. 

Auf "Großbild" um¬ 
schalten ! 

Vertikale Pos. 
schrittweise ändern. 
Neue Screenadresse 
berechnen 
und einstellen. 
Kleine Pause! 


Auf alten Screen 
zurückschalten. 
Benutzten Speicher 
wieder freigeben! 


Um unmittelbare Reaktionen zu erzielen (nach einer bestimmten Zahl von Bildschirmzeilen 
auf einen anderen Bildschärmspeicherbereich umzuschalten o. ä.), müßte man den Video- 
Address-Counter manipulieren können. Dieser enthält nämlich den Pointer auf das nächste 
Word im Bildschirmspeicher, das geholt und in Bildinformation umgesetzt werden soll. Beim 
ST ist der Video-Address-Counter ein 3-Byte-Read-only-RegisteT. 


Im STE hat Atari dieses Register ebenfalls für Schreibzugriffe zugänglich gemacht. 


Adresse 

Label 

R/W 

Bits 

Bedeutung 

$FF 8205 
vcounthi 

R/W 

XXHH HHHH 

Video-Address-Counter, High-Byte 

$FF 8207 
vcountmid 

R/W 

MMMMMMMM 

Video-Address-Counter, Med.-Byte 

$FF 8209 
vcountlow 

R/W 

LLLL LLL0 

Video-Address-Counter, Low-Byte 
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Beim Umgang mit diesem Register ist Vorsicht geboten, da das Resultat unmittelbar sichtbar 
wird. Eine Bedienung des Video-Address-Counters erscheint deshalb nur während des 
Horizontal-Blank sinnvoll. Dann ist der Elektronenstrahl im Monitor gerade vom Ende des 
Bildinhalts der just geschriebenen Bildschirmzeile zum Anfang des Bildinhalts in der neuen 
Zeile unterwegs und deshalb dunkel getastet. Für das Zählen der abgelaufenen Bildschirmzeilen 
kann man ja wieder den Timer B als Ereigniszähler verwenden (siehe auch im ST-Hardware- 
teil, Kapitel 4, “Der Multifunktionsbaustein MFP 68901”). 

Horizontales Finescrolling 

ist nicht gar so einfach zu realisieren. Denn hierbei muß ein Bild (genauer gesagt jede Bild¬ 
schirmzeile) an einem beliebigen Pixel beginnen können. Und das bedeutet nichts anderes, 
als daß man dem Videocontroller mitteilen muß, ab welcher Speicheradresse und ab welchem 
Bit in dieser Adresse denn die Bildschirmzeile beginnt. 

Im STE wurde dafür eigens das HScroll-Register geschaffen. 


Adresse 




Label 

RAV 

Bits 

Bedeutung 

$FF 8265 

RIW 

xxxxssss 

HScroll-Register, verzögert den 

hscroll 



Bildbeginn um SSSS bjnär Bits. 


Mit diesem Register sind Werte zwischen 0 und 15 einstellbar. Das bedeutet, daß zunächst 
SSSS bloilr -Pixel bei der Ausgabe als Bildinformation übersprungen werden. Bei HScroll = 0 hat 
man also keine horizontale Verschiebung auf dem Bildschirm und deshalb die gleichen 
Verhältnisse wie im ST. 

Im Monochrom-Betrieb ist dieses Verhalten am einfachsten darzustellen, da ja dann jedem 
Bit ein Pixel auf dem Bildschirm entspricht. Eine Zeile mit 640 Pixel besteht dann aus 80 auf¬ 
einanderfolgenden Bytes im Bildschirmspeicher. 

Weil der Videocontroller (genauer gesagt der SHIFTKR) im ST(E) nicht einzelne Bytes aus 
dem Bildschirmspeicher holt und als Bildinformation umsetzt, sondern das immer wordweise 
geschieht, ist also eine Bildschirmzeile 40 Words lang. 

Ist HScroll auf z. B. 5 eingestellt, so werden aus dem Word 0 des Bildschirmspeichers die 
höchstwertigen fünf Bits übersprungen und nicht als Bildinformation ausgegeben! 

Die Bildschirmzeile beginnt fünf Bits “später” mit Bit 10 des Word 0 des Bildschirmspeichers 
und ist 640 Bit (= 640 Pixel bei Monochrom) danach zu Ende. 
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Das letzte Pixel der ersten Zeile würde also dem Bit 11 des Word 40 vom Bildschirmspeicher 
entsprechen. Die zweite Bildschirmzeile fängt dann frühestens wieder (wegen HScrolI=5) mit 
Word 41, Bit 10 an und geht bis zu Word 81, Bit 11 usw. (siehe dazu auch Abbildung J.9). 



Abb. J.9: Organisation des Bildschirmspeichers im Monochrombetrieb mit HScroll-5 


Im Gegensatz zu der Organisation des Bildschirmspeichers mit HScroll=0 ist eine Zeile bei 
HScroll>0 also mindestens ein Word länger. Denn die Zeile beginnt ja nicht mehr an einer 
Word-Grenze, sondern um HScroll-Bits nach rechts verschoben. Da die Anzahl Bits/Zeile 
aber weiterhin gleichbleibt, “ragt” das Ende der Zeile um HScroll-Bits in das 41 .Word hinein! 

Um diesem Umstand Rechnung zu tragen, hat man im STE ein weiteres Hardware-Register 
eingeführt. Das Line-Width-Register (“linewid” an Adr. $FF 820F) gibt an, um wie viele 
Words die Zeile denn “länger” als eine normale Bildschirmzeile (normalerweise 40 Words/ 
hohe Auflösung, 80 Words/mittlere und niedrige Auflösung) ist. 

Da man hier ein 8-Bit-Register zur Verfügung hat, kann man hier Werte bis zu 255 verwenden. 
Das bedeutet aber auch nichts anderes, als daß man eine Bildschirmzeile im Speicher 255 
Words länger als die “normale” Zeile machen kann! 


Adresse 

Label 

R/W 

Bits 

Bedeutung 

$FF 820F 

RAV 

oooo oooo 

Line-width-Register 

linewid 



Versatz in Words bis zum Beginn 




der nächsten Bildschirmzeile 


Man kann also auch in horizontaler Richtung “große” Bildschirme aufbauen und dann durch 
entsprechende Einstellung des HScroll-Registers und des Bildschirmbasispointers (dbasehi, 
dbasel und dbaselow) jeweils den gewünschten Ausschnitt davon auf dem Bildschirm 
darstellen. Das nachfolgende Beispiellisting demonstriert das. 
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Dabei werden zwei “normale” Monochrom-Bilder (640 x 400=256 000 Pixel=16 OOOWords) 
“nebeneinander” in einen Buffer kopiert. Also erst 40 Words (1. Zeile) von Bild 1, dann 
40 Words (1. Zeile) von Bild 2, wieder 40 Words (2. Zeile) von Bild 1, dann 40 Words (2. 
Zeile) von Bild 2 usw. 

1000 ' Horizontales Scrolling mit STE (Einfaches Demo im Monochrom- 
' Modus!) 

1010 ' 


1020 ' Es werden zwei Bilddateien im Doodle-Format eingeladen und 
1030 ' "zu einem nebeneinanderliegenden" Großbild zusammenkopiert. 
1040 ' Dieses Großbild wird dann per horizontalem Scrolling einmal 
1050 ' "von links nach rechts abgefahren”! 

1060 ' 

1070 Lineoffs%L=$FF820F:' Benutzte Hardware-Reg. 

für Scrolling 

1080 Hscroll%I.=$FF8265 
1090 ' 

1100 MEMORY_BLOCK 00,64000,A%L :' Platz für zwei ".DOO"~ 

Bilddateien 

1110 MEMORY_BLOCK 01,64000,Buffer%L :' Platz für das "Großbild" 
1120 BLOAD "BILD__1.DOO", A%L :' Zwei Bilder einladen 

1130 BLOAD "BILD_2.DOO",A%L+32000 
1140 ' 

1150 XBIOS (Physbase%L,2 ):' Alte Bildschirm¬ 

speicheradresse merken. 

1160 ' 

1170 ' Beide Einzelbilder "nebeneinander" im Buffer ablegen. 

1180 FOR X%L=0 TO 399 

1190 MEMORY_MOVE A%L+X%L*80,80 TO Buffer%L+X%L*160 
1200 MEMORY__MOVE A%L+32000+X%L*80, 80 TO Buffer%L-l-X%L*160+80 

1210 NEXT X%L 
1220 ' 

1230 XBIOS (, 5,L -1,L Buffer%L, -1) :' Auf "Großbild" 

umschalten! 

1240 PORE Lineoffs%L, 39:' Lineoffs = 40-1 Words beim 

Scrollen 

1250 ' 

1260 FOR Xpos%L=0 TO 639:' Horizontale Position 

schrittweise ändern. 

1270 IF Xpos%L MOD 16=0 THEN Word-Grenze erreicht? 
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1280 Scrnadr%L=Buffer%L+Xpos%L SHR 3:' Ja! Neue Screen- 

adresse berech- 

1290 XBIOS (,5,L -1,L Scrnadr%L,-1):' nen und einstellen. 

1300 XBIOS (, 37): ’ Bis zum VBlank 

warten. 

1310 POKE Hscroll%L / 1 :' Hscroll = 0 überspringen. 

1320 ELSE 

1330 POKE Hscroll%L, Xpos%L AND $F:' Nein! Pixel-Delay 

setzen. 


1340 ENDIF 
1350 WAIT 7E-3:' 

1360 NEXT Xpos%L 
1370 ' 

1380 XBIOS (,5,L -1,L Physbase%L,-1) 

1390 POKE Hscroll%L,0:' 

1400 POKE Lineoffs%L,0 

1410 FRE (A%L): FRE (Buffer%L):' 


Kleine Pause! 


Auf alten Screen 
zurückschalten 
Alles wieder in 
Ausgangszustand 

Benutzten Speicher wieder 
freigeben! 


Um zum Schluß des Programms wiederauf die “normale” Bildschirmorganisation zurückgreifen 
zu können, wird der aktuelle Bildschirmbasispointer gerettet. Dann wird durch Neuladen des 
Bildschirmbasisspeichers mit der Anfangsadresse des “Großbildbuffers” auf den neuen 
Bildschirm geschaltet. Damit der Videocontroller des STE jetzt weiß, daß der Bildschirmspeicher 
“breiter” angelegt ist, wird das “linewid’-Register entsprechend eingestellt. 

In einer Schleife wird jetzt die Startposition des dargestellten Bildschirms ständig um ein Pixel 
nach rechts gerückt. Dabei wird das “HScroll”-Register entsprechend mit hochgezählt und ein 
pixelweises Scrollen nach rechts erreicht. Wenn mehr als 16 Pixel (= 16 Bit = 1 Word in 
Monochrom) gescrollt wurde, muß die Anfangsadresse des Bildschirmspeichers um ein gan¬ 
zes Word weitergeschaltet (hochgezählt) werden. Danach kommen wieder 16 Steps mit dem 
“HScrolF’-Register, gefolgt durch das Inkrementieren des Bildschirmbasispointers usw. 

Das Ändern der Videocontroller-Register sollte natürlich dann erfolgen, wenn es möglichst 
wenig auf dem Bildschirm stört, also am besten im VBlank. Die im Listing verwendete 
Xbios(,37)-Funktion (= Vsync) leistet dabei schon gute Hilfe. Zum Ende des Programms wird 
auf Standardeinstellung zurückgeschaltet und der alte Bildschirmbasispointer restauriert. 

Mit dieser Hardware-Unterstützung lassen sich also relativ einfach große Bitplanes im 
Speicher (virtuelle Playfields) bearbeiten. 
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Im Monochrom- und Low-Resoiution-Modus kommt es beim STE-Shifter bei H-Scrolling- 
Anwendungen zu kleinen Störungen im Bildaufbau, immer wenn das HSCROLL-Register 
von einem Nicht-Null-Wert auf Null geht! Atari empfiehlt deshalb, bei H-Scrolling-Anwen¬ 
dungen im Pixel-Raster die erforderlichen Display-Manipulationen bei solch einem bevorste¬ 
henden Wechsel von HSCROLL <> 0 auf HSCROLL = 0 nicht im VBlank, sondern kurz 
vorher durchzuführen! 

Atari schlägt folgende Vorgehensweise vor, um die für das horizontale Scrolling verwendeten 
Hardware-Register (Video-Base-Address, Hscroll und linewid) zum richtigen Zeitpunkt zu 
setzen. In einer VBlank-Interrupt-Routine werden jeweils die neuen Registerwerte ermittelt, 
aber erst später durch eine Interrupt-Routine gesetzt. Dieser Interrupt wird durch den als Bild¬ 
schirmzeilenzähler verwendeten Timer B des MFP ausgelöst! Wenn Hscroll auf Null wech¬ 
selt, werden die Hardware-Register während der letzten Display-Zeile geändert. Bei Hscroll=0 
wird nach der letzten Bildschirmzeile manipuliert! 


Speicheraufrüstung leicht gemacht - Atari geht 
mit der Zeit 

Im STE findet man endlich das RAM in zeitgemäßer Bauform, sprich als Bausteine, wie sie 
heute im Zeitalter fortgeschrittener Fertigungsmöglichkeiten immer verstärkter angeboten 
werden. Die Zeiten, in denen man für 4 MByte RAM auf der Platine noch den Platz eines 
halben DIN-A4-Blattes brauchte, sind nun langsam vorbei. Atari verwendet im STE zur 
Realisierung des RAMs sogenannte SIMMs. Dabei handelt es sich um kleine Platinenstreifen 
mit Direktsteckkontakten, auf denen je acht RAM-Chips in SMD-Technik aufgebracht sind. 
Diese “RAM-Streifen” gibt es sowohl zu256K x 8 Bit (z.B. “58256-10”) als auch IM x 8 Bit 
(z. B. “581000-10”) organisiert. Beide Typen können verwendet, sprich einfach in die vor¬ 
handenen vier Steckfassungen gesetzt werden. Damit lassen sich wieder die bereits vom ST 
bekannten Kombinationsmöglichkeiten für den RAM-Ausbau herstellen. Also RAM von 
1MByte über 2,5MByte bis zu 4MByte (in meiner Testmaschine) ist damit möglich. 


“Nimm SIMMS - dann stimmt’s” 

Die Einbindung der vier möglichen Fassungen mit “RAM-Streifen” ist im nachfolgenden 
Schaltungsauszug dargestellt. Je Bank sind auch hier wieder die Aufteilung in High-Byte und 
Low-Byte des Datenbusses zu sehen. Da auch hier Leitungen gespart werden sollen, wird der 
Adreßbus, wie in den STs, gemultiplext. 

Mit den neun Leitungen des Multiplex-Adreßbusses lassen sich folglich nacheinander 2 x 9 = 
18 Adreßleitungen übertragen und somit 2 18 = 1.048.576 Speicherzellen ansprechen. 
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Da die RAM-Streifen byteweise organisiert sind, kann man max. 1MByte je Streifen 
.ansprechen. 

Verv.'endet werden auch hier dynamische RAMs, deren Inhalt nach einer bestimmten Zeit 
wieder ‘aufgefrischt” werden muß. Außerdem muß man entsprechende Steuerinformationen 
für dieRAMs liefern, damit diese wissen, welche Hälfte der Adreßinformation gerade auf dem 
Multiplex-Adreßbus daherkommt. Dazu werden auch hier wieder die RAS- und CAS-Signale 
benötigt. 



Abb. J.10: Das RAM im STE 
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Anhang K: 

Die Echtzeituhr des MEGA-ST(E) 


Die Computer der MEGA-ST(E)-Serie besitzen alle einen batteriegepufferten Uhrenchip des 
Typs “RP5C15”. Auch die Tastaturcomputer des Typs STE könnten diesen Uhrenchip ansteu- 
em, die Steuersignale sind an der GSTMCU vorhanden! 

Ab TOS Version 1.02 (Blitter-TOS) wird dieser Uhrenchip auch benutzt, wenn er denn vor¬ 
handen ist! Das TOS übergibt die Zeit- und Datumsinformation an das GEMDOS, wenn das 
System initialisiert wird und jedesmal wenn ein Anwenderprogramm beendet wird (mit dem 
GEMDOS-Aufruf “PtermO”). 

Die Einbindung des Uhrenchips in die Hardware des MEGA-ST zeigt der in Abbildung K.l 
dargestellte Schaltungsauszug. Der Uhrenchip bekommt seinen Takt natürlich nicht vom 
Systemtakt, denn der “verschwindet” ja beim Ausschalten des Computers. Deshalb also noch 
ein zusätzlicher, eigener Quarz nur für den Uhrenchip. Wie der Schaltungsauszug zeigt, besitzt 
der Uhrenchip noch zwei weitere Anschlüsse, die von ATARI nicht benutzt werden. 

Zum einen wäre da der Open-Collector-Ausgang “_ALARM”. Der Uhrenchip kann nämlich 
nicht nur Zeit und Datum weiterzählen, sondern wie ein normaler Wecker zu einem bestimm¬ 
ten Datum und einer eingestellten Zeit ein Signal auslösen, Pin 15 des Uhrenchips schaltet im¬ 
mer dann nach Masse durch, wenn Alarmzeit und -tag mit den aktuellen Daten übereinstimmt. 
Das Durchschalten hält eine Minute an, weil danach ja Alarmzeit und aktuelle Zeit nicht mehr 
auf die Minute übereinstimmen. Damit dürften Bastler doch bestimmt etwas anfangen können 
(Interrupts auslösen o.ä.). 

Der zweite zu betrachtende Ausgang, der von ATARI freundlicherweise direkt auf einen 
Testpunkt herausgeführt wurde, ist der Pin 3 (CLKOUT) des Uhrenchips. Hier kann, je nach 
Programmierung eines der Register des Uhrenchips, ein Takt abgegriffen werden, der direkt 
aus dem Sy stemtakt des Uhrenchips abgeleitet wird. Welche Taktfrequenzen an diesem Open- 
Collector-Ausgang entnommen werden können, wird noch bei der Besprechung der Chip-Re¬ 
gister im einzelnen aufgeführt. Von einem Impuls pro Minute bis zu 16384 Impulsen pro Se¬ 
kunde sind hier möglich! 

Der Datenbus zum Uhrenchip ist auf ganze vier Leitungen zusammengeschrumpft. Mehr sind 
aber auch nicht erforderlich, da der Uhrenchip für jede Stelle der Uhrzeit- und Datums¬ 
information ein eigenes 4-Bit-Register besitzt. Die Selektion der einzelnen Register erfolgt 
über vier Adreßleitungen, obwohl der Uhrenchip über 32 Register (!) verfügt. Man bedient sich 
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dabei eines “Switch-Bits” in einem Register, mit dem man von einer Registerbank mit 16 Regi¬ 
stern auf eine zweite Registerbank umschalten kann. Das Register mit dem “Switch-Bit” ist 
natürlich in beiden Bänken vorhanden; wie sollte man sonst wieder zurückschalten können? 



Abb. KJ: Die Echtzeituhr im MEGA-ST 
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Die Register des Uhrenchips 

Die Register des Uhrenchips liegen im Adreßraum des ST auf ungeraden Adressen, sind je¬ 
doch auch als niederwertigstes Nibble mit Word-Zugriffen auf die jeweils darunterliegende, 
gerade Adresse zu erreichen. 

Nachfolgend die Tabelle mit den einzelnen Registern, deren Adresse und Bedeutung: 
Zunächst die Register für die Bank 0 

Bitbelegung 


Adresse 

D3 

D2 

Dl 

DO 

Bedeutung 

$FF FC21 

s 

s 

s 

s 

Sekunden-Einer (0..9) 

SFFFC23 

- 

s 

s 

s 

Sekunden-Zehner (0..5) 

$FF FC25 

m 

m 

m 

m 

Minuten-Einer (0..9) 

$FF FC27 

- 

m 

m 

m 

Minuten-Zehner (0..5) 

$FF FC29 

h 

h 

h 

h 

Stunden-Einer (0..9) 

$FF FC2B 

- 

- 

h 

h 

Stunden-Zehner (0..1 in 24h-Modus, sonst mit Bit 
Dl AM/PM-Anzeige im 12h-Modus (gesetztes Bit 
Dl-1 entspricht PM-Zeit)). 

SFFFC2D 

- 

w 

w 

w 

Wochentag (0 = Sonntag). Vom TOS nicht benutzt. 

$FF FC2F 

D 

D 

D 

D 

Tage-Einer (0..9) 

$FFFC31 

- 

- 

D 

D 

Tage-Zehner (0..3) 

$FF FC33 

M 

M 

M 

M 

Monate-Einer (0..9) 

$FF FC35 

- 

- 

- 

M 

Monate-Zehner (0..1) 

$FF FC37 

Y 

Y 

Y 

Y 

Jahre-Einer (0..9) 

SFFFC39 

Y 

Y 

Y 

Y 

Jahre-Zehner (0..9) (da das TOS immer in Jahren 
ab 1980 rechnet, wird für das Jahr 1988 in “Jahre- 
Einer” also eine 8 und für “Jahre-Zehner” eine 0 
eingetragen) 

FFFC3B 

ST 

AL 

- 

BK 

Modus-Register (Bitbedeutung siehe unten) 


“Switch-Bit” (0- Bank 0, 1= Bank 1 angewählt) 
Alarm-Bit (0= Alarm aus, 1= Alarm ein) 
Stop-Bit (0= Uhr Stop, 1= Uhr läuft) 
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Bitbelegung 

Adresse D3 D2 Dl DO Bedeutung 


$FFFC3D 0 0 0 0 Test-Register (alle Bits müssen 0 sein!) 

$FFFC3F TI T2 RS AR Reset-Register (Bitbelegung siehe unten) 

I Alarm-Reset (1= setzt alle Alarm-Reg. auf 0) 

————■ Uhr-Reset (1= setzt alle int. Uhr-Reg. zurück) 

--—- 16Hz ein (0= 16Hz-Impulse an Pin 15 ausgeben) 

- 1Hz ein (0= lHz-Impulse an Pin 15 ausgeben) 


Und nun die Register der Bank 1: 


Bitbelegung 

Adresse D3 D2 Dl DO Bedeutung 


$FF FC21 


SFFFC23 


C2 CI CO Diese drei Bits steuern die Impulsfolge, welche an 
I Pin 3 ausgegeben wird 


0 0 0 
0 0 1 
0 1 0 
0 1 1 
1 0 0 
1 0 1 
1 1 0 
1 1 1 


Open-Collector-Ausgang “CLKOUT” gesperrt 
Ausgangsfrequenz 16384 Hz 
Ausgangsfrequenz 1024 Hz 
Ausgangsfrequenz 128 Hz 
Ausgangsfrequenz 16 Hz 
Ausgangsfrequenz 1 Hz (Sekundentakt) 
Ausgangsfrequenz 1/60 Hz (Minutentakt) 
Open-Collector-Ausgang “CLKOUT” durch¬ 
geschaltet 


AD Adjust-Bit. Bei Setzen von Bit “AD” gehen die 
Sekundenregister auf 0! Wenn die Sekunden 
zwischen 30..59 waren, werden gleichzeitig die 
Minuten um 1 hochgezählt. 


SFFFC25 

am 

am 

am 

am 

SFFFC27 

- 

am 

am 

am 

SFFFC29 

ah 

ah 

ah 

ah 

$FF FC2B 

- 

- 

ah 

ah 

$FF FC2D 


aw 

aw 

aw 

$FF FC2F 

aD 

aD 

aD 

aD 


Alarmzeit Minuten-Einer (0..9) 
Alarmzeit Minuten-Zehner (0..5) 
Alarmzeit Stunden-Einer (0..9) 
Alarmzeit Stunden-Zehner (0..2) 
Alarmzeit Wochentag (0=Sonntag) 
Alarmzeit Tage-Einer (0..9) 
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Bitbelegung 


Adresse 

D3 

D2 

Dl 

DO 

Bedeutung 

$FF FC31 

_ 

_ 

aD 

aD 

Alarmzeit Tage-Zehner (0..3) 

$FF FC33 

- 

- 

- 

- 

Nicht benutzt! 

$FF FC35 

- 

- 

- 

24 

Ist das “24”-Bit gesetzt, so arbeitet der Uhrenchip 
im 24h-Modus. 

$FF FC37 

- 

- 

SJ 

SJ 

Schaltjahr-Register (es wird mit den Jahren von 

0..3 hochgezählt, 0 = Schaltjahr!) 

SFFFC39 

_ 


- 

- 

Nicht benutzt! 

SFFFC3B 

ST 

AL 

- 

BK 

Modus-Register (Wie in Bank 0) 

$FF FC3D 

0 

0 

0 

0 

Test-Register (Wie in Bank 0) 

$FF FC3F 

TI 

T2 

RS 

AR 

Reset-Register (Wie in Bank 0) 


Wie man sieht, ist dieser kleine Chip doch ganz schön leistungsfähig. Leider wird vom 
Betriebssystem außer der Abfrage des laufenden Datums und der Uhrzeit kaum von den 
Möglichkeiten Gebrauch gemacht. 

Die Alarmfunktion des Chips kann man leider nicht nutzen, da die gegenwärtige TOS-Version 
nichts Besseres zu tun hat, als das Register “Alarmzeit Minuten-Einer” zum Test zu benutzen, 
ob denn der Uhrenchip überhaupt anwesend ist. Dazu wird bei der Systeminitialisierung ein 
unsinniger Wert in dieses Register geschrieben und anschließend verglichen, ob dieser Wert 
auch wirklich dort steht (= Chip vorhanden). Leider wird vor dem Test nicht der augenblick¬ 
liche Inhalt des Registers gerettet und nach dem Test wieder zurückgeschrieben! 

Zu allem Überfluß werden beim Aufruf der XBIOS-Funktion #22 (“Settime”) und auch der 
GEMDOS-Funktionen#43 (“Tsetdate”) und#45 (“Tsettime”) zwar die Zeit- und Datumsregister 
im Uhrenchip korrekt gesetzt, aber im Modus-Register wieder das Alarm-Bit gelöscht, und 
ins RESET-Register wird ein Wert von $2 eingeschrieben. Das führt dann dazu, daß der 
Alarm-Ausgang ständig im 1 Hz- und 16 Hz-Takt gegen Masse schaltet. 

Hat man nun (wie im Schaltbild angegeben) beispielsweise eine Leuchtdiode angeschlossen, 
so flackert diese im ständigen Takt,statt nur dann zu leuchten, wenn ein Alarm ausgelöst wird. 

Außerdem wird bei jedem GEMDOS-Aufruf, der zum Verlassen eines Programms dient, der 
Uhrenchip ausgelesen. Dazu testet aber das TOS wieder jedesmal, ob der Uhrenchip denn vor¬ 
handen ist, was dann zu dem bereits beschriebenen Überschreiben der Register Alarmzeit Mi¬ 
nuten-Einer und -Zehner und dem Rücksetzen des Alarmbits im Modusregister führt. 
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Will man also die Alarm-Funktion des Uhrenchips zumindest bei eingeschaltetem Rechner 
benutzen (z. B. als Weckfunktion durch Aufleuchten der Leuchtdiode. Statt der Leuchtdiode 
läßt sich aber auch, wie in Abbildung K. 1 bereits angedeutet, eine Treiberschaltung ansteuem, 
über die ein Relais geschaltet wird, das dann z. B. einen Netzverbraucher einschaltet.), so sollte 
man zum Stellen von Uhrzeit/Datum nicht die XBJOS-bzw. GEMDOS-Funktion benutzen, 
sondern eigene Routinen verwenden, welche die Alarmfunktion des Uhrenchips unterstützen 
und nicht unterdrücken! 

Eine Möglichkeitfüreineeingeschränkte Nutzung der Alarmfunktion besteht darin, GEMDOS- 
Aufrufe, die zu einer Veränderung der Alarmregister führen, abzufangen. Dazu muß man den 
Vektor, der auf den GEMDOS-Dispatcher im ROM zeigt, auf eine eigene Routine umleiten. 
Diese testet bei jedem GEMDOS-Aufruf, ob Alaimregister zerstört werden könnten. Wäre das 
der Fall, liest man sich den gegenwärtigen Stand der Alarmregister aus und speichert diesen 
zwischen. Anschließend kann man den GEMDOS-Aufruf ausführen, der die Alarmdaten im 
Uhrenchip zerstört, und restauriert nach diesem GEMDOS-Aufruf wieder die Alarmregister 
mit den zwischengespeicherten Werten. 
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Im MEGA ST ist über den MEGABUS-Anschluß eine Karte mit einem 16 MHz-Coprozessor 
des Typs MC68881 nachrüstbar. Beim MEGA STE dagegen ist dieser Coprozessor im Plati¬ 
nenlayout bereits vorgesehen und teilweise direkt mit eingebaut. Daaber in beiden Rechnertypen 
weiterhin eine MC68000er-CPU zum Einsatz kommt, muß das Kommunikationsprotokoll 
zwischen CPU und Coprozessor per Software nachgebildet werden. Erst die Prozessoren 
68020/68030 beherrschen dieses Protokoll selbst. Siehe dazu auch die Erläuterungen im Kapi¬ 
tel “Damit’s noch schneller geht - der Coprozessor MC68882". 

Beim MC68000 wird dagegen bei Erkennen eines Coprozessor-Befehls ein sogenannter Line- 
F-Trap ausgelöst, weil das höchstwertige Nibble des ersten Coprozessor-Befehlsworts $F lau¬ 
tet. 

Da in früheren TOS-Versionen der Line-F-Trap von ATARI für bestimmte Betriebssystemcalls 
verwendet wurde, ist es beim Einsatz eines Coprozessors evtl, erforderlich, diesen Trap abzu¬ 
fangen und Coprozessorbefehle entsprechend demnachfolgend näher erläuterten Kommunika¬ 
tionsprotokoll an die FPU weiterzuleiten (wie so ein Treiber in der Praxis aussehen könnte, 
war mal in der c’t 4/90, “Schneller rechnen”, beschrieben.) Für die MC68000-CPU erscheint 
der Coprozessor wie ein Peripheriebaustein, der bestimmte Register besitzt und darüber ange¬ 
sprochen wird. 


Die Coprozessor Interface Register (CIR) 

Für den Austausch von Signalen und Daten zwischen CPU und Coprozessor sind eine ganze 
Zahl von internen Registern in der FPU vorgesehen. Das Registermodell dieser Coprozessor 
Interface Register (CIR) stellt sich für den Programmierer wie folgt dar: 


Adresse: 


SFFFA40 

Response 

(READ) 

$FF FA42 

Control 

(WRITE) 


Save 


WORD-Zugriffe 


SFFFA44 


(READ) 
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Adresse: 


$FF FA46 

Restore (RAV) 



$FF FA48 

Operation Word (*) 

WORD-Zugriffe 


SFFFA4A 

Command (WRITE) 



$FF FA4C 

(Reserved) (*) 



$FF FA4E 

Condition (WRITE) 



$FF FASO 

Operand 

(RAV) 

$FF FA54 

Register Select (R) 

WORD-Zugriffe 


SFFFA56 

(Reserved) (*) 



$FF FA58 

Instruction Address 

(WRITE) 

$FFFA5C 

Operand Address (*) 


LONG 


LONG 

LONG 


Die mit (*) versehenen Register haben (noch) keine Funktion. 


Über das Response-Register erfährt die CPU durch Auslesen, wie weit die FPU mit der 
Abarbeitung von einem Coprozessor-Befehl gekommen ist bzw. was die FPU von der CPU 
als nächstes erwartet. Es müssen ja evtl, noch Operanden in die FPU gebracht oder auch von 
dort abgeholt werden. Außerdem werden über dieses Register Informationen über an den 
Coprozessor gestellte Bedingungsabfragen (“wahr” oder “falsch”) ausgetauscht. 

Die CPU muß also bei der Emulation des Protokolls mit dem Coprozessor dieses Register aus- 
lesen und nach Auswertung entsprechend darauf reagieren. 

Die im Response-Register übergebenen 16 Bit-Words werden auch als sogenannte Response 
Primitives bezeichnet. Die FPU beginnt mit der Ausführung eines neuen Befehls immer erst 
nach dem erstmaligen Auslesen des Response-Registers! 

Ein Schreibzugriff auf das Control-Register (egal mit welchem Wert!) bewirkt beim MC 
68881 einen Abbruch aller FPU-Operationen! Der MC68881 ist damit bereit für eine neue 
Operation. Das Ziel-FP-Datenregister einer so unterbrochenen Operation ist unbestimmt! 
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Die Save- und Restore-Register wird man im ST(E) wahrscheinlich selten gebrauchen, da sie 
für das Sichern und Wiederherstellen des Coprozessor-internen Zustands z. B. wegen eines 
Taskwechsels verwendet werden können. Deshalb soll hier nicht weiter darauf eingegangen 
werden. 

Was die FPU eigentlich tun soll, erfährt sie in der Regel über das Command- Register! Durch 
einen Schreibzugriff wird der “normale” Dialog zwischen CPU und Coprozessor gestartet. 
Hier “landet” das zweite Befehlsword eines “normalen” Coprozessor-Befehls. 

Das Condition -Register wird verwendet, wenn eine Bedingungsabfrage ausgeführt werden 
soll. Dabei landet dann das zweite Coprozessor-Befehlsword (mit den Bedingungsabfrage- 
Bits) in diesem Register! Ob die Bedingung erfüllt wurde oder nicht, teilt der Coprozessor dann 
über das Response-Register mit. 

Das Operand-Register kann beschrieben und gelesen werden. Es dient dem Transfer von 
Daten zwischen CPU und FPU. Die Breite beträgt zwar 32 Bit, aber es können natürlich auch 
Operanden in Byte- oder Word-Größe übergeben werden. Wichtig dabei ist, daß alle Operan¬ 
den in diesem Register immer “linksbündig” übergeben werden. D. h. beispielsweise, daß 
Byte- Operanden in den Bits 24..31 des Registers übergeben werden! 

Wenn mehrere FP-Datenregister mit dem FMOVEM-Befehl transportiert werden sollen, so 
muß die FPU der CPU natürlich irgendwie mitteilen können, welche und wie viele FP-Register 
dies sind. Dazu werden die oberen acht Bits des Register se/ecr-Registers benutzt. Sie ent¬ 
halten die Registermaske. Ein gesetztes Bit signalisiert jeweils ein zu transferierendes FP-Re- 
gister. Dabei kommt es gar nicht mal auf die Reihenfolge der gesetzten Bits an, sondern viel¬ 
mehr auf die Anzahl! So weiß die CPU dann, wie viele Registerinhalte bewegt werden müssen 
(jedes FP-Datenregister benötigt 12 Bytes Platz!). 

Das Instruction Address -Register kann bei der Programmierung eines MC68881 außer acht 
gelassen werden. Hier wird dem Coprozessor bei Bedarf (nur beim MC68882 mit seiner 
parallelen Betriebsweise für verschiedene Befehle) der augenblickliche Wert des CPU- 
Programmzählers übergeben. Der MC68882 verlangt das immer dann, wenn eine Exception 
durch einen FPU-Befehl ausgelöst werden könnte. Damit hat ein Trap-Handler für FPU- 
Exceptions dann später die Möglichkeit, den Befehl, bei der die Exception auftrat, festzustel¬ 
len und dort wieder aufzusetzen. 


Das Protokoll 


Die Kommunikation mit dem Coprozessor muß üblicherweise nach dem folgenden Schema 
ablaufen: 
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1. Die CPU trifft auf einen Coprozessor^ Line-F)-Befehl und löst eine Ausnahmeverar¬ 
beitung aus. In dieser Ausnahmeverarbeitungsroutine muß dann das entsprechende CIR 
mit befehlsspezifischen Informationen geladen werden. 

Bei “normalen” Befehlen wird das Command-Register mit dem zweiten Coprozessor- 
Befehlswort geladen und so der Dialog CPU <-> FPU gestartet. 

Bedingungsanfragen an die FPU werden durch Einschreiben des zweiten Befehlsworts 
in das Condition-Register gestartet. 

2. Durch Auslesen des Response-Registers erfährt die CPU über die Response primitives, 
ob die FPU noch mehr Daten benötigt. Folgende Möglichkeiten ergeben sich: 

- Die FPU ist “beschäftigt”! Also kann sich die CPU erstmal um evtl, aufgelaufene 
Interrupts usw. kümmern. Nach “getaner Arbeit” wird dann wieder im Response- 
Register der Stand der Dinge geprüft. 

- Es liegt eine Exception-Bedingung von seiten der FPU vor. Der entsprechende 
Exception-Vektor geht aus der Response primitive hervor. Die CPU kann die 
Ausnahmeverarbeitung einleiten. 

- Die FPU möchte etwas durch die CPU erledigt haben (Adreßberechnung für zu 
transportierende Daten und die Durchführung des Transports durch die CPU. 
Außerdem kann die FPU signalisieren, daß die CPU nach “getaner Arbeit” wieder 
im Response-Register nachschaut.). 

Die FPU ist mit allem versorgt und signalisiert der CPU, daß sie sich mit “ihrem 
eigenen Kram” beschäftigen soll. 

Die Durchführung des Protokolls hängt natürlich von den im ersten Coprozessor-Befehlswort 
enthaltenen Daten ab. Weitere wichtige Informationen sind dem zweiten Befehlswort zu ent¬ 
nehmen. Deshalb soll hier kurz auf deren Struktur eingegangen werden. 


Das erste Coprozessor-Befehlswort 

hat folgenden Aufbau: 


15 

0 

1 

1 

1 

1 

Cp-ID 

i r i 

i i 

Typ , 

1- 1 1 1 - S - 

t Abhängig ( vom Typ 


Durch das Cp-ID-Feld können max. acht Coprozessoren angesprochen werden. 
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Standardmäßig verwendet Motorola in seinem Assembler jedoch nur die Cp-ID = 001 bj[i . Im 
Typ-Feld ist kodiert, um welche Art Coprozessor-Befehl es sich handelt: 


Typ 

Bedeutung 

000 

Normaler Befehl (Rechenoperation oder Datentransport-Befehl) 

00 1 

FDBcc, FScc, FTRAPcc 

0 1 0 

FBcc.W 

0 1 1 

FBcc.L 

100 

FSAVE (internen FPU-Zustand sichern) 

101 

FRESTORE (internen FPU-Status wiederherstellen) 

1 1 0 

(Reserved) 

111 

(Reserved) 


Die Bedeutung der Bits 0..5 ist vom Befehlstyp abhängig. Bei normalen Befehlen bestimmen 
die Bits 3..5 (Modus-Bits) den Adressierungsmodus, und in Bit 0..2 (Register-Bits) steht dann 
die Register-Nummer der CPU (wenn denn ein Register beteiligt ist). 


115 0 


i 1 

1 

1 

1 

I 1 

Cp-ID 

_i_ i _ 

f i — 

Typ i 

1 1 

Modus 

— i — i — 

Register 
- 1 - 1 _ 


Adressierungs¬ 

modus 

Mode 

Bits 

Register- 

Bits 

Dn 


Reg.-Nummer des Datenreg. der CPU 

An 


Reg.-Nummer des Adreßreg. der CPU 

(An) 

010 

Reg.-Nummer des Adreßreg. der CPU 

(An)+ 

0 1 1 

Reg.-Nummer des Adreßreg. der CPU 

-<An) 

100 

Reg.-Nummer des Adreßreg. der CPU 

(d l6 ,An) 

101 

Reg.-Nummer des Adreßreg. der CPU 

(d g ,An,Xn) 

1 1 0 

Reg.-Nummer des Adreßreg. der CPU 

(bd,An,Xn) 

1 1 0 

Reg.-Nummer des Adreßreg. der CPU (*) 

([bd,An,Xn],od) 

1 1 0 

Reg.-Nummer des Adreßreg. der CPU (*) 

([bd,An],Xn,od) 

1 10 

Reg.-Nummer des Adreßreg. der CPU (*) 

(xxx).W 

111 

000 

(xxx).L 

111 

001 

#<data> 

111 

100 

(d 16 >PC) 

111 

0 10 

(d 8 ,PC,Xn) 

111 

0 l 1 
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Adressierungs¬ 

Mode 

Register- 

modus 

Bits 

Bits 

(bd,PC,Xn) 

1 1 1 

0 1 1 (*) 

([bd,PC,Xn],od) 

1 1 1 

0 1 1 (*) 

((bd,PC],Xn,od) 

1 1 1 

0 1 1 (*) 


(*)= Adressierungsart existiert beim MC68000/68010 nicht! 


Der Aufbau des zweiten Coprozessor-Befehlsworts 

Das Command-Word hat bei allen arithmetischen Befehlen und den Datentransportbefehlen 
(außer FSINCOS, FMOVECR, FMOVE from FPcr und FMOVEM) den folgenden Aufbau: 


15 0 


0 

R/M 

0 

-1-i- 

Source 

_1_1_ 

1 ' 1 

Dest.-Reg. 

_i-1- 

-1 1 1 !-1-1- 

Befehlsnummer 

_1_i_!_i_i_i_ 


Folgende Zuordnung gilt, wenn das R/M-Bit gesetzt ist: 


Source¬ 
bits (*) 

Bedeutung 

000 

Datenformat ist LONG 

00 1 

Datenformat ist Single Real 

010 

Datenformat ist Extended Real 

01 1 

Datenformat ist Packed Decimal 

100 

Datenformat ist WORD 

1 0 1 

Datenformat ist Double Real 

1 10 

Datenformat ist BYTE 


(*)= Nur beim Befehl “FMOVE from FPn" verwendet! 

Wenn das R/M-Bit allerdings gelöscht ist, wird in den Sourcebits die Nummer des Floatingpoint- 
Registers (FPn) angegeben, welches als Quelle benutzt wird. 

Die drei Dest.-Reg-Bits geben die Nummer des Floating-Point-Registers an, welches als Ziel 
verwendet werden soll. In der Befehlsnummer ist die Nummer des jeweiligen Befehls 
enthalten. 
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(Die Befehle sind im Kapitel “Damit’s noch schneller geht - Der Coprozessor MC68882" von 
ihrer Funktion her kurz beschrieben!): 


Befehls¬ 

nummer 

Befehlsmnemonic 

Befehls- 

nummer 

Befehlsmnemonic 

0 

FMOVEtoFPn 

$18 

FABS 

1 

FINT 

$19 

FCOSH 

2 

FSINH 

$1A 

FNEG 

3 

FTNTRZ 

$1C 

FACOS 

4 

FSQRT 

$1D 

FCOS 

6 

FLOGNP1 

SIE 

FGETEXP 

8 

FETOXM1 

$1F 

FGETMAN 

9 

FTANH 

$20 

FDTV 

$A 

FATAN 

$21 

FMOD 

$C 

FASIN 

$22 

FADD 

$D 

FATANH 

$23 

FMUL 

$E 

FS1N 

$24 

FSGLDIV 

$F 

rr AN 

$25 

FREM 

$10 

FETOX 

$26 

FSCALE 

$11 

FTWOTOX 

$27 

FSGLMUL 

$12 

FTENTOX 

$28 

FSUB 

$14 

FLOGN 

$38 

FCMP 

$15 

FLOG 10 

$3A 

FTST 

$16 

FLOG2 




Der Befehl FSINCOS berechnet ja zugleich Sinus und Kosinus einer Zahl. Er hat als 
Befehlsnummer den Wert von $3X. Dabei muß für X die Nummer des zweiten FP-Ziel- 
registers angegeben werden, wo dann der Wert des berechneten Kosinus landet! 

Mit dem FMOV£C/?-Befehl kann man häufig benötigte Konstanten (Pi, e usw.) aus einem 
Konstanten-ROM der FPU holen. Der Wert für den Offset in dieses ROM wird dazu in den 
unteren sieben Bits des Command-Words eingetragen. 


15 


1-1 I I I I 1 

ROM-Offset 


1 

0 

1 

1 

1 

-1-1- 

Dest.-Reg. 


Eine Liste dieser Konstanten mit Offset-Werten ist ebenfalls in dem Kapitel “Damit’s noch 
schneller geht - Der Coprozessor MC68882" enthalten. 
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Die Dest,-Reg,-Bits müssen mit der entsprechenden Nummer des Ziel-FP-Registers geladen 
werden. 

Mit FMOVE front FPn wird ein FP-Register ausgelesen und an einer Zieladresse (darf auch 
ein CPU-Register sein, wenn die Operandenlänge Byte, Word oder Long ist!) abgelegt. 


15 0 


0 

1 

1 


ESSS 

i r~ r i i i 

k-Faktor 

_i_i_i_i_i_i_ 


In den Source-Reg.-Bits ist die Nummer des Quell-FP-Regi sters anzugeben. 

Bei k-Faktor ist eine Formatangabe zu machen, wenn das Ergebnis im Packed Decimal-For- 
mat erstellt werden soll (Näheres zum k-Faktor im Kapitel “Damit’s noch schneller geht - Der 
Coprozessor MC68882"). 

Die Angabe muß im Zweierkomplement erfolgen. 

Wenn mit dynamischem k-Faktor gearbeitet wird (der k-Faktor steht dann in einem Datenreg. 
der CPU), so ist in den Bits 4..6 die Nummer des CPU-Datenregisters anzugeben (Bits 0..3 
bleiben dann gelöscht!). 

Die Dest.-Form.-Bits sind nach der folgenden Tabelle kodiert: 


Dest.- 

Format 

Bedeutung 

000 

Datenformat ist LONG 

001 

Datenformat ist Single Real 

010 

Datenformat ist Extended Real 

0 1 1 

Datenformat ist Packed Decimal (statischer k-Faktor) 

100 

Datenformat ist WORD 

101 

Datenformat ist Double Real 

1 1 0 

Datenformat ist BYTE 

111 

Datenformat ist Packed Decimal (dynamischer k-Faktor) 


Mit FMOVE FPcr wird auf die Control-Register der FPU zugegriffen. Das Command-Word 
dazu sieht folgendermaßen aus: 
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15 


-r- 1 

Register 


DR 


0 0 0 0 0 0 0 0 


0 01= FPIAR (FP-Instruction Address Register) 
0 10 = FPSR (FP-Status Register) 

10 0 = FPCR (FP Control Register) 

Direction (0 = Move nach FPcr) 

(1 = Move aus FPcr) 


Mehrere Control-Register der FPU werden mit dem FMOVEM FPcr bewegt. 

[ 15 | 0 


1 


0 DR 


t -r 


Register 

_i_i_ 


0 

0 

0 

0 

0 

- 1 

0 

0 

0 

0 


I— 0 0 0 = (Reserviert) 


0 01= FPIAR 
010 = FPSR 

011= FPSR, dann FPIAR 

10 0 = FPCR (FP Control Register) 

101= FPCR, dann FPIAR 

110 = FPCR, dann FPSR 

111= FPCR, dann FPSR, dann FPIAR 

Direction (0 = Move nach FPcr) 

(1 = Move aus FPcr) 


Mehrere FP-Datercregisterinhalte können ebenfalls mit einem FMOVEM FPn-Befehl trans¬ 
portiert werden. 

115 |0 


1 

0 

DR 

-1- 

Modus 

_i_ 

0 

0 

0 

11 1 1 1 1 1 
Liste der zu transp. Register 


— 1 = Statische Registerliste 

0 = Dynamische Registerliste 

— 1 = (An)+ 

0 = -(An) 

— Direction (0 = Move nach FPcr) 

(1 = Move aus FPcr) 
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Die Modus-Bits legen den Adressierungsmodus fest und wie die Liste der Register vorliegt. 

Statische Liste Die untersten achtBits stellen eine Auswahlmaske für die zu transportie¬ 

renden Register dar. Wenn ein Register bewegt werden soll, ist das ent¬ 
sprechende Bit gesetzt, sonst gelöscht! 

Aufbau der Liste: 





Bitnummer 





Adr.-Art 

7 

6 

5 

4 

3 

2 

1 

0 

-(An) 

FP7 

FP6 

FP5 

FP4 

FP3 

FP2 

FP1 

FPO 

(An)+ 

FPO 

FP1 

FP2 

FP3 

FP4 

FP5 

FP6 

FP7 


Dynamische Liste Die FP-Register-Auswahlmaske steht in einem CPU-Datenregister. Die 
Nummer des CPU-Datenregisters ist in den Bits 4..6 des Command- 
Words eingetragen. Der Listenaufbau ist der gleiche wie bei der stati¬ 
schen Liste, nur daß eben die acht untersten Bits des CPU-Datenregisters 
diese Maske enthalten müssen! 

Nun zu den “nicht normalen” Coprozessor-Befehlen. FPU-Anweisungen, die FPU-Be- 
dingungscodes auswerten, wie FScc, FDBcc, FTRAPcc und FBcc enthalten ja schon im er¬ 
sten Coprozessor-Befehlswort (das mit $F.. beginnt!) eine andere Typkennung. Damit wer¬ 
den sie von den “normalen Befehlen” abgegrenzt. 

Der Aufbau dieser Befehle ist wegen der unterschiedlichen Benutzung der unteren sechs Bits 
des ersten Coprozessor-Befehlsworts deshalb nochmal komplett mit allen erforderlichen 
Befehlsworten angegeben. 

FSee-Befehl ($FF -> Reg./Speicherstelle, wenn Bedingung erfüllt) 


115 |0 


1 

1 

1 

1 

-, — —,- 

CP-ID 

0 

0 

1 

1 1 1 1 

Modus Register 

0 

0 

0 

0 

0 0 0 

0 

0 

0 

t r— | i— 

Bedingungsabfrage 


Modus- und Register-Bits haben die gleiche Bedeutung, wie bereits bei der Erläuterung des 
ersten Coprozessor-Befehlsworts gezeigt. Die Bedingungsabfrage-Bits enthalten dabei das 
Bitmuster, mit der die Abfrage kodiert ist. 
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Die so “formulierte” Bedingung ist dann von der FPU auszuwerten und am Ende der Bear¬ 
beitung mit “Ja” oder “Nein” an die CPU zu beantworten. 

Die Beantwortung erfolgt dann über ein Bit im Response-Register. 


Bedingungs-Bits 

Mnemonic 

Bedeutung 

0 

0 

0 

0 

0 

0 

F 


Falsch 

0 

0 

0 

0 

0 

1 

EQ 


Gleich 

0 

0 

0 

0 

1 

0 

OGT 


Größer 

0 

0 

0 

0 

1 

1 

OGE 


Gleich oder größer 

0 

0 

0 

1 

0 

0 

OLT 


Kleiner 

0 

0 

0 

1 

0 

1 

OLE 


Kleiner oder gleich 

0 

0 

0 

1 

1 

0 

OGL 


Größer oder kleiner 

0 

0 

0 

1 

1 

1 

OR 


Größer, kleiner oder gleich (es ist kein NAN!) 

0 

0 

1 

0 

0 

0 

UN 


(Die gleichen Bedingungsbits wie vorher, 

0 

0 

1 

0 

0 

1 

UEQ 


nur daß hiermit geprüft wird, ob 

0 

0 

1 

0 

1 

1 

UGT 


eine nicht zulässige Zahl (NAN) 

0 

0 

1 

1 

0 

0 

UGE 


entstanden ist bzw. bei der letzten 

0 

0 

1 

1 

0 

1 

ULE 


Verknüpfung mit “im Spiel war”!) 

0 

0 

1 

1 

1 

0 

NE 


yy »♦ yy yy yy 

0 

0 

1 

1 

1 

1 

T 


yy yy » yy 

0 

1 

0 

0 

0 

0 

SF 


In diesem Teil der Tabelle werden die 

0 

1 

0 

0 

0 

1 

SEQ 


gleichen Bedingungsabfragen wie vorher 

0 

1 

0 

0 

1 

0 

GT 


nochmals mit ihren (aber anderen) Mnemonics 

0 

1 

0 

0 

1 

1 

GE 


aufgeführt. 

0 

1 

0 

1 

0 

0 

LT 



0 

1 

0 

1 

0 

1 

LE 


Durch das gesetzte Bit 4 wird der 

0 

1 

0 

1 

1 

0 

GL 


FPU bei solchen Bedingungsabfragen 

0 

1 

0 

1 

1 

1 

GLE 


signalisiert, daß eine Exception 

0 

1 

1 

0 

0 

0 

NGLE 


ausgelöst werden soll, wenn bei 

0 

1 

1 

0 

0 

1 

NGL 


der Bedingungsabfrage ein NAN 

0 

1 

1 

0 

1 

0 

NLE 


mit “im Spiel war”! 

0 

1 

1 

0 

1 

1 

NLT 


(Das BSUN-Bit im EXC-Byte des FPSR 

0 

1 

1 

1 

0 

0 

NGE 


wird dann gesetzt!) 

0 

1 

1 

1 

0 

1 

NGT 



0 

1 

1 

1 

1 

0 

SNE 



0 

1 

1 

1 

1 

1 

ST 
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FDßcc-Befehl 

Syntax: FDBcc Dn,<label> 

Funktion: IF Bedingung cc wahr, THEN No Operation 

ELSE Dn : = Dn - 1; 

IF Dn <> -1, THEN go to <label> 


15 | 0 



D 

n 

D 

■ 


■ 

0 

0 

i 

l1 

0 0 1 

1 1 

iüsb 

0 

0 

0 

0 

0 

0 

0 

0 

° 

0 

1 1 

Bedingung; 

i i 

r i i 
sabfrage 

_1 


1_ 

1_1 


1 ! 

16-B 

:_ i 

! 

it-Spn 

mgdist 

:anzw( 
!_1 

ert 

1 1 1 

I_i_I_l 

i _l_i_ 


Bei Reg.-Dn ist die Nummer des CPU-Datenregisters einzutragen, welches dekrementiert 
wird, wenn die Bedingung nichterfüllt ist. Di e,Bedingungsabfrage-Bits sind wie in der Tabelle 
zuvor zu setzen. 

Das dritte Coprozessor-Befehlsword enthält dann den Sprungdistanzwert im Zweierkomple¬ 
ment. 

FTRAPcc- Befehl 

Syntax: FTRAPcc.W #<data> 

FTRAPcc.L #<data> 

Funktion: Wenn die Bedingung cc erfüllt ist, wird ein Trap ausgelöst und der evtl. folgen¬ 

de Operand dem Traphandler übergeben. 


i 15 | 0 


1 

1 

i 

i 


1 

CP-ID 

_l_ 

0 

0 

i 

1 |- 

111 Modus 

i i 

0 

0 

0 

0 

0 







16- 

_ 

Bit- 

_ 

Opera 

nd o 

1 

der höher 

_i_ 

werti 

_ 

ges 

_ 

Aford 1 

i 1 I 1 r 

)ei 32-Bit~Operand 

_ i _i i i i 

n i i i i i i i s i i i i i-1 

niederwertiges Word bei 32-Bit-Operand (wenn erforderlich) 

iii iii i ii i i i i i i 
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Modus: 010 Operand ist 16 Bits lang 

0 11 Operand ist 32 Bits lang 
10 0 Es folgt kein Operand! 


FZfcc-Befehl 

Syntax: FBcc. w <label> 

FBcc.L <label> 

Funktion: Wenn die Bedingung cc erfüllt ist, wird zum <label> verzweigt. 


15 I 0 


1 

D 


D 





BBI 


16- 

_ 






i i i i i i 

ord bei 32-Bit-Distanz 
i i_ j _i_i_i_i_ 

! j i i i i l l i l | i i ii 

niederwertig. Word bei 32-Bit-Sprungdistanzwert (wenn erforderlich) 
_ 1 _ 1 _1_ __1 _J_L _1_— .1. _ J_ 1 _ 1 _ 1 __ 1 _ 1 _ 


Sz 0=16 Bit-Sprungdistanzwert 
1 — 32 Bit-Sprungdistanzwert 

Der Sprungdistanzwert ist im Zweierkomplement anzugeben! 


FAW-Befehl 

Syntax: FNOP 

Funktion: No Operation! 


15 

0 

1 

1 

1 

1 

! 

[ 1 
CP-IE 

1 

0 

1 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 


Es folgen die Spezialbefehle für das Sichern und Wiederherstellen des FPU-Zustandes - z. B. 
wegen eines Taskwechsels in Multitasking-An Wendungen. Sie unterscheiden sich im ersten 
Coprozessor-Befehlsword nur im S/R-Bit. Ein zweites Befehlsword ist nicht erforderlich! 
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15 0 


1 

1 

1 

1 

-!-r——i 

Cp-ID 

i i 

1 

0 

S/R 

1 1 
Modus 

i i 

i i 

Register 


0 = FSAVE; 1 = FRESTORE 


Modus- und Register-Bits haben die gleiche Bedeutung, wie schon bei den “normalen” 
Befehlen erläutert. 


Die Coprozessor Response primitives 

Wie ja schon weiter oben erwähnt, kann die CPU durch Auslesen des Response-Registers 
feststellen, wie weit die FPU ist bzw. was diese noch z. B. an Daten benötigt. Die FPU geht 
davon aus, daß nach dem Auslesen des Response-Registers der entsprechende Inhalt von der 
CPU übernommen wurde und entsprechend ausgewertet wird! Das bedeutet, daß die FPU 
schon intern Weiterarbeiten kann, bis sie wieder über das Response-Register weitere Service- 
Anfragen an die CPU signalisiert! Diese als Response primitives bezeichneten 16-Bit-Worte 
sollen nun kurz erläutert werden. 


Null primitive 

Diese Response primitive wird hauptsächlich zur Synchronisation zwischen CPU und FPU 
benutzt. Daran kann die CPU nämlich erkennen, ob die FPU noch beschäftigt ist oder ob später 
nochmal “nachgeschaut” werden soll! 


15 0 


CA 

PC 

0 

0 

0 

0 

0 

IA 

0 

0 

0 

0 

0 

0 

PF 


CA Come again-Bit. Wenndas Bit gesetzt ist, bedeutet das, daß die CPU nach Erledigung 

der angeforderten Aufgaben das Response-Register nochmals auslesen soll. 

PC Pass-Program-Counter-Bit. Ein gesetztes Bit bedeutet: Programmzählerinhalt soll 
sofort der FPU im Instruction Address-Register übergeben werden. Kann beim MC 
68881 ignoriert werden. 

LA Interrupts-Allowed-Bit. Durch ein gesetztes Bit signalisiert die FPU, daß sich die 
CPU (bei Bedarf) um anstehende Interrupts kümmern darf. 
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PF Process-Finished-Bit. Ein gesetztes Bit meldet der CPU, daß die FPU zu neuen Taten 

bereit ist. Ist das Bit gelöscht, so ist die FPU noch mit einer Operation beschäftigt. 

TF True/False-Bit. Das Resultat einer Bedingungsanfrage an die FPU wird hiermit 
signalisiert. TF = 0; Bedingung nicht erfüllt! TF = 1: Na, raten Sie mal! 


Evaluate effective address and transfer data primitive 

Diese Response primitive tritt auf, wenn Daten zwischen FP-Daten- oder -Control-Registern 
und CPU-Registem oder Speicherbereichen ausgetauscht werden sollen. Die CPU hat anhand 
der Daten in dieser Primitive und den im ersten Coprozessor-Befehlswort enthaltenen Mode- 
und Register-Bits die gewünschte “Effektive Adresse” zu ermitteln und eine entsprechende 
Anzahl von Bytes (wie viele, steht in “Länge”!) Uber das Operanden-Register zu transportie¬ 
ren. 


15 | 0 


CA 

PC 

DR 

1 

0 

-1-1- 

EA 

_i_i_ 

i l l l l II 

Länge 

_i_i_i_i_i_i_i_ 


Das CA- und PC-Bit haben die gleiche Bedeutung, wie bei der Null primitive beschrieben. 

DR Direction-Bit. Bestimmt die Datentransportrichtung. Ein gesetztes Bit sagt der CPU, 

daß aus der FPU (über das Operanden-Register) gelesen werden soll. 

EA Kodierbits für die Klasse der Effektiven Adresse. Hiermit gibt die FPU die Klasse 
der effektiven Adresse an, die ermitteltund dann zum Datentransport verwendet wer¬ 
den soll. Die genaue Bestimmung, ob die effektive Adresse ein CPU-Register, Spei¬ 
cher oder Konstante ist, wird ja durch die Mode- und Register-Bits im er¬ 
sten Coprozessor-Befehlswort vorgenommen. Mit den EA-Bits kann nur noch mal 
geprüft werden, ob die vereinbarte Adressierungsklasse auch mit der Kodierung in 
den Mode- und Register-Bits übereinstimmt. Kann ignoriert werden. Wer sich für die 
genaue Zuordnung von Adressierungsklassen zu Adressierungsarten interessiert, sei 
auf das “MC68881/68882Floating-Point Coprozessor User ’ s Manual” von Motorola 
verwiesen. 

Länge Das Längen-Feld gibt die Anzahl der Bytes an, die beim Datentransport über das 
Operanden-Register bewegt werden müssen. Mögliche Werte sind 1 (Byte), 2 
(Word), 4 (Long oder Single Precision), 8 (2 FPCR oder Double Precision) oder 12 
(alle 3 FPCR, Extended Precision oder Packed dezimal). 
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Transfer single main processor register primitive 

Diese Primitive wird verwendet, um den Inhalt eines CPU-Registers zur FPU zu übertragen 
(übergeben wird der CPU-Registerinhalt wieder “linksbündig” über das Operand-Register der 
FPU!). 

Verwendung findet diese Primitive bei dem Dialog anläßlich eines FMO VEM FPn-Befehls. 
Wenn nämlich die Liste der zu übertragenden FP-Datenregister als dynamische Liste vorliegt 
(also als Bitmaske in einem CPU-Datenregister!), bekommt die CPU hiermit angezeigt, wel¬ 
ches CPU-Register diese Liste enthält. Die CPU hat dann den Registerinhalt im Operanden¬ 
register zu übergeben. 

115 10 


CA 

PC 

DR 

0 

1 

1 

0 

0 

0 

0 1 

0 

0 

D/A 


Das CA- und PC-Bit haben die gleiche Bedeutung, wie bei der Null primitive beschrieben. 
Das DR-Bit legt wieder die Transportrichtung fest (1 = FPU => extern). 

D/A Data-/Address-Register-Bit. Ein gelöschtes Bit signalisiert, daß ein CPU-Datenregister 

gemeint ist. Sonst geht’s um ein Adreßregister (kommt nicht vor!). 

Regist. Hiermit wird die Registemummer (0..7) übergeben. 


Transfer multiple coprocessor registers primitive 

Wird benutzt beim Transfer von mehreren FPU-Registern. Die Quelle oder das Ziel des 
Datentransports (die “effektive Adresse”) geht ja bereits aus den Mode- und Register-Bits im 
ersten Coprozessor-Befehlswort hervor. Die Liste der zu transferierenden Register muß die 
CPU nach Erkennen dieser Primitive aus dem Register select-Register auslesen! 

Jedes gesetzte Bit entspricht dabei einem Transfer von in “Länge” angegebener Menge von 
Bytes! 


15 I 0 


CA 

PC 

DR 

0 

0 

0 

0 

1 

-!-j-1-j——,-i-i- 

Länge 

iii i i it 


Das CA-, PC- und DR-Bit haben die gleiche Bedeutung, wie bereits zuvor beschrieben. 
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Länge Operandenlänge in Bytes. 

Auf die Response primitives für die Exception-Bearbeitung soll hier nicht näher eingegangen 
werden. Wenn der Coprozessor als Peripheriebaustein betrieben wird (im ST(E) der Fall), 
kommen diese speziellen Anwendungen ohnehin kaum vor! 

Wer aber auch das bis ins Detail wissen will (muß), sollte auf das bereits mehrmals erwähnte 
MC68881/68882-Usermanual zurückgreifen. 
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Anhang M: 

Kurzübersicht über die Hardware-Register 


Beim TT finden sich die Hardware-Register zum einen im ST-Adreßraum, zum anderen am 
oberen “Ende” des Speicherbereichs (ab Adresse $FFFF 8000). Angegeben ist jeweils nur die 
Adresse im ST-Adreßraum! 


Speicherkonfiguration 

Adresse Zugriff Bezeichnung Label 


$FF 8001 RAV Memory-Config.-Register (Byte) memconf 

-cccc 

Bank 1 

00-- 64 KBit Chips (128 KByte/Bank) 

01- 256 KBit Chips (512 KByte/Bank) 

10 - 1 MBit Chips (2 MByte/Bank) 

11 - Reserviert 

BankO 

00 - 64 KBit Chips (128 KByte/Bank) 

01 -- 256 KBit Chips (512 KByte/Bank) 

10 -— 1 MBit Chips (2 MByte/Bank) 

11 -Reserviert 

Achtung! Diese Bitbelegung gilt nicht beim TT! 

Videocontroller 


Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 8201 

RAV 

Video-Base-Reg. High (Byte) 

dbaseh 

$FF 8203 

RAV 

Video-Base-Reg. Mid (Byte) 

dbasel 

$FF 8205 

R(*> 

Video-Adr.-Counter High (Byte) 

vcounthi 

$FF 8207 

R<*> 

Video-Adr.-Counter Mid (Byte) 

vcountmid 

$FF 8209 

R(*> 

Video-Adr.-Counter Low (Byte) 

vcountlow 


(*) = Beim STE ist auch Schreiben möglich! 
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Adresse 


$FF 820A 


$FF 820C 


$FF 8240 


SFF 8242 
$FF 8244 
$FF 8246 
$FF 8248 
$FF 824A 
$FF 824C 
SFF 824E 
SFF 8250 
SFF 8252 
SFF 8254 
SFF 8256 
$FF 8258 
SFF 825A 
SFF 825C 
$FF 825E 


Zugriff Bezeichnung 


Label 


R/W Sync-Mode-Register (Byte) syncmode 

-V S 

^-Synchronisation (0= Intern, 1 ^Extern) 

(Beim TT genau andersherum!!!) 

-Vertikalfrequenz (0=60 Hz, 1=50 Hz) 

(Nicht beim TT!) 

R/W Video-Base-Reg. Low (Byte) dbaselow 

(Nur bei TT/STE-Maschinen!) 

R/W - rRRR gGGG bBBB Farbreg. 0 colorO 

- 0 = Normal Monochrom 

1 = Invertiert Monochrom 


R/W 

-rRRR 

gGGG bBBB 

Farbreg. 1 

colorl 

R/W 

-rRRR 

gGGG bBBB 

Farbreg. 2 

color2 

R/W 

-rRRR 

gGGG bBBB 

Farbreg. 3 

color3 

R/W 

-rRRR 

gGGG bBBB 

Farbreg. 4 

color4 

R/W 

-rRRR 

gGGG bBBB 

Farbreg. 5 

color5 

R/W 

-rRRR 

gGGG bBBB 

Farbreg. 6 

colorö 

R/W 

-rRRR 

gGGG bBBB 

Farbreg. 7 

color7 

R/W 

-rRRR 

gGGG bBBB 

Farbreg. 8 

color8 

R/W 

-rRRR 

gGGG bBBB 

Farbreg. 9 

coIor9 

R/W 

-rRRR 

gGGG bBBB 

Farbreg. 10 

colorlO 

R/W 

-rRRR 

gGGG bBBB 

Farbreg. 11 

colorl 1 

R/W 

-rRRR 

gGGG bBBB 

Farbreg. 12 

colorl2 

R/W 

-rRRR 

gGGG bBBB 

Farbreg. 13 

colorl 3 

R/W 

-rRRR 

gGGG bBBB 

Farbreg. 14 

colorl 4 

R/W 

-rRRR 

gGGG bBBB 

Farbreg. 15 

colorl 5 


R = Rot-Intensität (r = LSB nur bei TT/STE) 
G = Grün-Intensität (g = LSB nur bei TT/STE) 
B = Blau-Intensität (b = LSB nur bei TT/STE) 
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Adresse Zugriff Bezeichnung 


Label 


$FF 8260 RAV 


$FF 8262 RAV 


$FF 827E RAV 


ST-Shift-Mode-Register (Byte) shiftmd 

-SS 

Hör.- x Vert.-Auflösung 

0 0 - 320x200,4 Planes (16 Farben) 

01 - 640x200,2 Planes (4 Farben) 

10 - 640x400,1 Plane (Monochrom) 

11 - Reserviert 


TT-Shift-Mode Register (Word) shift_tt 

S—H-MMM-PPPP 

-^-— Reg.-Bank-Nr. 

für ST-Palette 
000 ST-Low (320 x 200,4 Planes) 

001 ST-Mid (640 x 200,2 Planes) 

010 ST-High (640 x 400, 1 Plane) 

011 <Reserviert> 

100 TT-Mid (640 x 480,4 Planes) 

101 <Reserviert> 

110 TT-High (1280 x 960,1 Plane) 

111 TT-Low (320 x 480, 8 Planes) 

-—— Hyper-Mono-Modus 

- Sample & Hold-Mode 

Register existiert nur im TT! 


STACY Display-Steuerung 

- 1 £>- (Byte) 



=1: Display Off 
“1: Beleuchtung Off 


stacydsp 


Register existiert nur im STACY (STBOOK?) 





1352 


ATARI Profibuch 


TT-Farbpalettenregister 

Register existieren nur beim TT! 


Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 8400 
$FF 8402 

R/W 

RAV 

-KRRr GGGgBBBb TT-Pal. 0 

-RRRrGGGgBBBb TT-Pal. 1 

TT_col0 

TT_coll 

$FF 85FC 
$FF 85FE 

RAV 

RAV 

-RRRrGGGgBBBb TT-Pal. 254 

-RRRrGGGgBBBb TT-Pal. 255 

r, g, b = Least Significant Bits! 

TT_col254 

TT_col255 

DMA-Controller 



Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 8604 

RAV 

Controller-Access-Register 

(nur wenn DMA-Mode-Reg., Bit 4=0!) 

diskctl 

oder 


Sector-Counter-Register 

(nur wenn DMA-Mode-Reg., Bit 4=1!) 



Word-Zugriff, nur Low-Byte benutzt! 

$FF 8606 R DMA-Status-Register (Word) fifo 

-SSS (Nur Low-Byte relevant!) 


i— 0= Fehler bei DMA-Op. 

— 0= Sekt. Count. Reg. = 0 

— 0= DATA REQ. v. FDC/ACSI inaktiv 
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Adresse Zugriff Bezeichnung 


Label 


W DMA-Mode-Register (Word) fifo 

-CCCCCCCC- 

| '- CA1 (Achtung! Cmd-Phase für AC- 

SI-Bus oder FDC-Reg.-Adressierg.) 
- CA2 

- 1- ACSI-, 0= FDC-Zugriff 

-1= Sect.-Cnt.-Register 

0= Contr.-Acc.-Register 

0-Reserviert 

0-- Reserviert (int. Verwendung) 

-— 1= DMA mit FDC 

0= DMA mit ACSI-Bus 

0=DMA-Read 

1= DMA-Write an Periph. 


$FF 8609 

R/W 

DMA-Base+Count.-Reg.-High (Byte) 

dmahigh 

$FF 860B 

RAV 

DMA-Base+Count.-Reg.-Mid (Byte) 

dmamid 

$FF 860D 

RAV 

DMA-Base+Count.-Reg.-Low (Byte) 

dmalow 
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Floppy Disk Controller WD1770/1772 



Abb. M.l: So wird ein Track im Speicher zusammengebaut und dann mit dem Befehl WRITB 
TRACK auf Disk geschrieben (Formatierung) 


eden Sektor 
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T HP 

Befehl 


Konnandobyte 



Bit 7 

6 

& 

4 

3 

2 

1 

0 


I 

RESTORE 

0 

0 

8 

0 

h 

u 

rl 

rfl 

I 

SEEK 

0 

0 

8 

1 

h 

V 

ri 

r0 

I 

STEP 

e 

8 

X 

U 

h 

V 

rl 

r 8 

I 

STEP— IH 

8 

1 

8 

u 

h 

V 

rl 

P0 

I 

STEP-OUT 

8 

1 

1 

u 

h 

u 

rl 

rß 

II 

READ SECTOR 

1 

8 

8 

n 

h 

E 

0 

o 

II 

«RITE SECTOR 

X 

0 

X 

N 

h 

E 

p 

a8 

III 

READ ADDRESS 

1 

1 

0 

0 

h 

E 

0 

8 

III 

READ TRACK 

1 

1 

1 

0 

h 

E 

0 

0 

III 

MRITE TRACK 

1 

1 

1 

1 

h 

E 

P 

0 

IV 

FORCE INTERRUPT 

1 

1 

0 

1 

*3 

Ib 

I, 




Abb. M.2: Die Kommandos des Floppy-Controllers WD1772 
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Bit-Hr. 

Bedeutung 

7 

Zustand des 'Motor on'-Anschlusses (*1' = Motor on) 

6 

Bei READ SECTÜR und READ TRACK ohne Funktion. Bei jeden 
WRITE—Befehl wird hiernit ein Sthreibschutz angezeigt. 

5 

Tgp I-Konnandos: Gesetzt sobald Motor-'Spin up' erfolgt ist. 

CG Indexpulse nach 'Motor on 1 3 

Typ 11» ,111-Konnandos: ‘1'= Sektor nit 'Deleted* —Data nark. 

*0' = Sektor nit 'Ualid'-Data nark. 

4 

Gesetztes Bit zeigt an, daß gewünschter Sektor, Spur oder 
Seite nicht gefunden wurde. TRecord not found) 

3 

Gesetzt wenn CRC-Error festgestellt wurde. 

2 

Typ I-Konnandos: Zustand des 'Track BO‘-ftnschlup. 

( 1‘ = Kopf über Spur BBJ 

Typ II..III-Konnandos: Wird '1' wenn die CPll CDMftJ bein Da¬ 
tentransfer zu lanysan reagiert hat. 

C'Lost Data'—Bit'l 

1 

Typ I-Konnandos! Zustand des Index-Anschiuß 

Typ II..III-Konnandos: Zustand des DRQ~Ansehluß. 

fl' = Data Register nuß 'bedient' 
werden.J 

0 

•BUSV'-Bit. Ein Konnando ist in Bearbeitung. 


Abb. M.3: Die Bedeutung der Bits im FDC-Status-Register 


SCSI-DMA (Nur TT!) 


Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 8701 

RAV 

DMA-Address-Pointer (Highest Byte) 

tt_dmabas 

$FF 8703 

RAV 

DMA-Address-Pointer (High Byte) 

tt_dmabas+2 

$FF 8705 

RAV 

DMA-Address-Pointer (Low Byte) 

tt_dmabas+4 

$FF 8707 

RAV 

DMA-Address-Pointer (Lowest Byte) 

tt_dmabas+6 

$FF 8709 

RAV 

DMA-Bytezähler (Highest Byte) 

tt_dmacnt 

$FF 870B 

RAV 

DMA-Bytezähler (High Byte) 

tt_dmacnt+2 

$FF 870D 

RAV 

DMA-Bytezähler (Low Byte) 

tt_dmacnt+4 

$FF 870F 

RAV 

DMA-Bytezähler (Lowest Byte) 

tt_dmacnt+6 

$FF 8710 

R 

Restdatenregister (High-Word) 

tt_dmarsd 

SFF8712 

R 

Restdatenregister (Low-Word) 

tt_dmarsd+2 

$FF 8714 

RAV 

Kontroliregister (Word) 

tt_dmactl 


•BC0000ED 


Richtung (1= WRITE) 
DMA-Enable (1= On) 
=1: Byte Count auf 0 
=1: Bus Error bei DMA 
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SCSI-Controller 5380 (Nur TT!) 

Adresse Zugriff Bezeichnung 


$FF 8781 R 
oder W 

$FF 8783 W 


$FF 8783 R 


$FF 8785 R/W 


Akt. Inhalt des SCSI-Datenbusses 


Ansgabedaten für SCSI-Datenbus 


Initiator-Befehlsregister 


cccccccc 


(Byte) 

Assert Data to Bus 
Assert _ATN 
Assert _SEL 
Assert „BSY 
Assert „ACK 
0 

Test Modus 
Assert RST 


Initiator-Befehlsregister 


CCCCCCCC 
L 


(Byte) 

Assert Data to Bus 
Assert _ATN 
Assert _SEL 
Assert _BSY 
Assert „ACK 
Lost Arbitration 
Arbitration in Progress 
Assert RST 


Betriebsartenregister 




(Byte) 

Arbitrate (=1: On) 
DMA-Mode (=l:Qn) 
Monitor Busy 
Enable End of Process-Int. 
Enable Parity Interrupt 
Enable Parity Check 
=1: Targetmode 
=1: Blockmode-DMA 


Label 

s_data 

s„data 

s_icr 


sjcr 


s_mode 
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Adresse Zugriff Bezeichnung 


Label 


$FF 8787 RAV 


$FF 8789 R 


W 


Target Befehlsregister s_tcr 

0000TTTT (Byte) 

1 I_ Assert ..I/O 

L_ Assert _C/D 

_ Assert _MSG 

- Assert _REQ 


Busstatusregister 

ssssssss 


s idstat 


(Byte) 

Zustand Parity-Line 
Zustand _SEL (Inaktiviert) 
Zustand _I/0 
Zustand _C/D 
Zustand MSG ” 

Zustand _REQ ” 

Zustand JBSY ” 

Zustand RST ” 


ID-Mask f. SELECTION-Phase 


sidstat 


$FF 878B R 


Statusregister 

SSSSSSSS 



(Byte) 

Zustand _ACK (I=aktiviert) 
Zustand _ATN “ 

1 - Busy Error 
1 = Phase match 
I = IRQ aktiv 
I = Parity Error 
1 = DMA-Request steht an 
1 = End of DMA 


s_dmastat 



W 

Start DMA-Ausgabe 

s_dmastat 

$FF 878D 

R 

Eingabedaten vom SCSI-Bus 

s„targrcv 


W 

Start Target-DMA-Eingabe 

s_targrcv 

$FF 878F 

R 

Reset Interrupts + Parityfehler 

s_inircv 


W 

Start Initiator-DMA-Eingabe 

s_inircv 
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Soundchip AY-3-8910 

Adresse Zugriff Bezeichnung Label 


$FF 8800 R 


Selektiertes Reg. auslesen 


giread 


W Chip-Register anwählen 

-ssss 


giselect 


| | Reg.-Nr. 

0000 - 0 

00 01- 1 

0010- 2 

0011- 3 

0100- 4 

0101- 5 

0110- 6 


0111- 7 


Bitbelegung Registerfunktion 


PPPPPPPP Per.-Dauer Low (A) 

... .PPPP Per.-Dauer High (A) 

PPPPPPPP Per.-Dauer Low (B) 

... .PPPP Per.-Dauer High (B) 

PPPPPPPP Per.-Dauer Low (C) 

.... PPPP Per.-Dauer High (C) 

.. .RRRKR Per.-Dauer 

Rauschen 

PPRRRSSS Mix-Ctrl. 

+I/0-Portsel. 

- Sound A aus 

(0-Ein) 

-- Sound B aus 

(0=Ein) 

- Sound C aus 

(0=Ein) 

- Rauschen A aus 

(0=Ein) 

- Rauschen B aus 

(0=Ein) 

- Rauschen C aus 

(O-Ein) 

- Port A auf OUT 

(0=EST) 

'-Port B auf OUT 

(0=IN) 
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Adresse Zugriff Bezeichnung 


Label 


W 

giselect 


Chip-Register anwählen 


—ssss 






Reg.-Nr. Bitbelegung 

1 

.oc 

)0 

8 

-MLLLL 

1001 

9 

-MLLLL 

1010 

10 

-MLLLL 


Registerfunktion 

Vol. A / 

Envelope Ein 
Vol. B / 

Envelope Ein 
Vol. C / 

Envelope Ein 
Level-Ctrl.-Bits(LCB) 
l=Env. Generator Ein 
0=Volume durch 
LCB 


1011 

11 

PPPPPPPP 

Per.-Dauer Env. 

Low 

1100 

12 

PPPPPPPP 

” ” High 

1101 

13 

-CEEE 

Hüllkurvenform 

1110 

14 

DDDDDDDD 

I/O Port A (Ausg. 

- Disk Side (l=Side 0) 


- Drv-Sel. A (0=Select) 

- Drv-Sel. B (0=Select) 

- RS 232 RTS-Leitg. 

— RS 232 DTR-Leitg. 
Strobe Parallelport 
P.3 Monitor-Buchse 
(ST) 

— SPEAKER ON/TT 

— CLKDIR/ 

MEGA STE 

t — 0=LAN 

- 1=SERIAL2 

(Nur TT + MEGA 
STE) 


1111 


15 


DDDDDDDD 


I/O Port B (Parallel- 
Port für Drucker) 
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Adresse Zugriff 

Bezeichnung 

Labei 

SFF 8802 W 

Schreiben in angew. Reg. 

giwrite 

DMA-Sound-Subsystem 


Diese Register existieren im ST nicht! 


Adresse Zugriff 

Bezeichnung 

Label 


$FF 8900 RAV Sound-DMA-Control sndmactl 

-re (WORD) 


DMA-Sound Enable 
(l=Ein) 

Frame Repeat (1-Repcat) 


SFF 8902 

R/W 

Frame-Start-Adr. High-Byte 

- OOHH HHHR 

sndbashi 

SFF 8904 

RAV 

Frame-Start-Adr. Middle-Byte 

-- MMMM MMMM 

sndbasmi 

$FF 8906 

RAV 

Frame-Start-Adr. Low-Byte 

- LLLL LLLL 

sndbaslo 

SFF 8908 

RAV 

Frame-Adr.-Counter High-Byte 

- OOHH HHHH 

sndadrhi 

SFF 890A 

RAV 

Frame-Adr.-Counter Middle-Byte 

-- MM^lM MMMM 

sndadrmi 

SFF 890C 

RAV 

Frame-Adr.-Counter Low-Byte 

- LLLL llll 

sndadrlo 

SFF 890E 

RAV 

Frame-End-Adresse High-Byte 

- OOHH HHHH 

sndendhi 

SFF 8910 

RAV 

Frame-End-Adresse Middle-Byte 

- MMMM MMMM 

sndendmi 

SFF 8912 

RAV 

Frame-End-Adresse Low-Byte 

- LLLL LLLL 

sndendlo 

SFF 8920 

RAV 

Sound-Mode- 

- b 

Control sndmode 

1000 OOKR(Word) 

' II 

00 — 6258 Hz Samplerate 

01-12517 Hz ” 

10- 25033 Hz ” 

11 - 50066 Hz ” 

-0 - Stereo /1 - Mono 
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Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 8922 

RAV 

MICRO WIRE<™> Adr.+Data-Bits 

DDDD DDDD DDDD DDDD 

MWDATA 

$FF 8924 

RAV 

MICRO WIRE<™> Mask-Register 

MMMM MMMM MMMM MMMM 

MWMASK 


Uhrenchip des TT 

Nachfolgend aufgefühlte Register existieren nur im TT! 



Abb. M.4: Die Register des TT-Uhrenchips 


Adresse Zugriff Bezeichnung 


Label 


$FF 8961 R/W 


Registerauswahl im Uhrenchip 


rtc_mr 
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Adresse Zugriff Bezeichnung Label 


$FF 8963 RAV Daten des selekt. Uhrenregisters rtc_data 

Reg. 

Nr. Bitbeleg. Bedeutung 

$A UDDDRRRR 

| 

!-1-Rate-Select f. Int.-Periode 

—-Divider-Ctrl. (Taktfrequenz!) 

1= Update in Progress 

$B SPAUQD2Z 

I-l"Sommer-/Winterzeit umschalten 

-l_24-Stunden-Modus 

-— l=Zeitwerte in Binär, sonst BCD 

*•-- 1=SQW-Ausgang einschalten 

Update ended-Int. Enable 

-Alarm-Int. Enable 

-Periodic-Int. Enable 

-l=Uhr stellen (Update gestoppt) 

$C IPAU0000 

I 

1 -Update ended Int.-Flag 

-Alarm-Int. Flag 

-Periodic-Int.-Flag 

-Int. Request-Flag (1 =Int. steht an) 

$D VOOOOOOO 

^-1= RAM und Zeitwerte sind gültig 


Blitter 

Nachfolgende Register existieren nicht im TT! 

Adresse Zugriff Bezeichnung Label 

$FF 8A00 RAV Halftone-RAM, Word 0 Halftone 

$FF 8A1E RAV 


Halftone-RAM, Word 15 
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Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 8A20 

R/W 

Source-X-Inc.-Reg. (Word) 

Src_Xinc 

$FF 8A22 

R/W 

Source-Y-Inc.-Reg. (Word) 

Src_Yinc 

$FF 8A24 

R/W 

Source-Address-Reg. (Long!) 

Src_addr 

$FF 8A28 

R/W 

ENDMASK I (Word) 

Endmaskl 

$FF 8A2A 

R/W 

ENDMASK 2 (Word) 

Endmask2 

$FF 8A2C 

R/W 

ENDMASK 3 (Word) 

Endmask3 

$FF 8A2E 

R/W 

Dest.-X-Inc.-Reg. (Word) 

Dst_Xinc 

$FF 8A30 

R/W 

Dest.-Y-Inc.-Reg. (Word) 

Dst_Yinc 

$FF 8A32 

R/W 

Dest.-Address-Reg. (Long!) 

Dst_Addr 

SFF 8A36 

R/W 

Worte/Zeile im Bit-Block (Word) 

X_Count 

$FF 8A38 

R/W 

Zeilen/Bit-Block (Word) 

Y_Count 

$FF 8A3A 

R/W 

Halftone-OP-Register (Byte) 

HOP 


Verknüpfungsergebnis zwischen Halftone- 
und Source-Daten 

00— Alle Bits =“1” 

01— NurHalftone 

10— Nur Source 

11 — Halftone AND Source 

$FF 8A3B R/W Log. OP-Register (Byte) OP 

- 0000 

(Verknüpfg. zwischen Quell- und Zieldaten) 

0000 — Ziel = “0” 

0001— Ziel = Quelle AND Ziel 

0010 — Ziel = Quelle AND NOT Ziel 

0011 — Ziel = Quelle 

0100— Ziel = NOT Quelle AND Ziel 

0101— Ziel = Ziel 

0110— Ziel = Quelle XOR Ziel 
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Adresse Zugriff Bezeichnung 


Label 


$FF 8A3B RAV Log. OP-Register (Byte) OP 

-OOOO 

INI 

0111 — Ziel = Quelle OR Ziel 

1000 — Ziel = NOT Quelle AND NOT Ziel 

1001 — Ziel = NOT Quelle XOR Ziel 

1010 — Ziel = NOT Ziel 

1011 — Ziel = Quelle OR NOT Ziel 

1100 — Ziel = NOT Quelle 

1101 — Ziel = NOT Quelle OR Ziel 

1110 — Ziel = NOT Quelle OR NOT Ziel 

1111 — Ziel = “1” 


$FF 8A3C RAV 


$FF 8A3D RAV 


Line-Number-Register (Byte) Line_Num 

BHS-LLLL 



Line-# für Halftone-RAM 
Smudge (Line-# aus Source Buffer) 
HOG-Bit (Buszugriff Blitter <-> CPU) 
0= Blitter 4- CPU abwechselnd 
1= Blitter allein, CPU gestoppt 

Busy-Bit (1= Transfer starten) 


SKEW-Register (Byte) Skew 

FN--SSSS 

I I I 

i -" Bitversatz zwischen Quell- und Ziel-Block 

I-NFSR (No Final Source Read) 

-FXSR (Force Extra Source Read) 


SCC-DMÄ (Nur TT!) 

Adresse Zugriff Bezeichnung Label 


$FF 8C01 RAV 


DMA-Address-Pointer (Highest Byte) 


scdmabas 
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Adresse 

Zugriff 

Bezeichnung 

Label 

$FF 8C03 

RAV 

DMA-Address-Pointer (High Byte) 

scdmabas+2 

$FF 8C05 

RAV 

DMA-Address-Pointer (Low Byte) 

scdmabas+4 

$FF 8C07 

RAV 

DMA-Address-Pointer (Lowest Byte) 

scdmabas+6 

$FF 8C09 

RAV 

DMA-Bytezähler (Highest Byte) 

scdmacnt 

$FF 8C0B 

RAV 

DMA-Bytezähler (High Byte) 

scdmacnt+2 

$FF 8C0D 

RAV 

DMA-Bytezähler (Low Byte) 

scdmacnt+4 

$FF 8C0F 

RAV 

DMA-Bytezähler (Lowest Byte) 

scdmaent+6 

$FF 8C10 

R 

Restdatenregister (High-Word) 

scdmarsd 

$FF 8C12 

R 

Restdatenregister (Low-Word) 

scdmarsd+2 

$FF 8C14 

RAV 

Kontrollregister (Word) 

scdmactl 


BC0000ED 



Richtung (1=WRITE) 
DMA-Enable (1= On) 
=1: Byte Count auf 0 
=1: Bus Error bei DMA 


Serial Communications Controller (SCC) 


Dieser Baustein existiert nur im TT/MEGA STE! 


Adresse Zugriff Bezeichnung 


Label 


$FF 8C81 R/W 

$FF 8C83 RAV 

$FF 8C85 RAV 

$FF 8C87 RAV 


CtrhReg. Kanal A 
Data-Reg. Kanal A 
CtrLReg. Kanal B 
Data-Reg. Kanal B 


sccctl_a 

sccdat_a 

sccctl_b 

sccdat_b 


Die Control-Register werden auf folgende Weise in zwei Stufen “bedient”: 

- Der erste Schreibzugriff auf die Control-Register “landet” in Write-Register 0 des ent¬ 
sprechenden SCC-Kanals und wird zur Einstellung der gewünschten Registemummer 
verwendet. 


Der nächste Zugriff (Schreiben oder Lesen) auf das Control-Register erreicht dann das 
im ersten Zugriff ausgewählte Register! 
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Die Data-Register erlauben mit einem Schreibzugriff direktes Einschreiben eines Bytes in den 
Sendebuffer (Write-Register 8). Bei einem Lesezugriff erhält man das Byte aus dem Emp¬ 
fangsbuffer (Read-Register 8). 

Also ist ein Zugriff auf die “zeitkritischen Daten” ohne große Umwege möglich. 

Näheres zum komplexen Registersatz des SCC findet sich im TT-Hardware-Teil, Kapitel 7, 
“Seriell, aber schnell - Der SCC macht’s möglich”. 


System Control Unit (SCU) 

Dieser Baustein übernimmt im TT/MEGA STE u .a. das Interrupt-Handling. Im ST/STE ist 
der Baustein nicht vorhanden! 


Adresse Zugriff Bezeichnung 


Label 


$FF 8E01 RAV 


$FF 8E03 R 


$FF 8E05 RAV 

$FF 8E07 RAV 

$FF 8E09 RAV 

$FF 8E0B RAV 


System Int. Mask-Register sys_mask 

SSSSSSS- (Byte) 



System-Soft.-Int. (l=akti viert) 
HSYNC-Interrupt (l=aktiviert) 
Nicht benutzt 

VSYNC-Interrupt (l=aktiviert) 
IRQ von SCC (Inaktiviert) 

IRQ von MFPs (l=aktiviert) 
_SYSFAIL-Int. VME (1-aktiviert) 


System Int. Status-Register 

Bitbelegung wie vor. Gesetzte Bits 
stellen Interruptanforderungen dar. 

(Vor “sys_mask” auslesen, da Lese¬ 
zugriff auf “sys_mask” IRQs zurück¬ 
setzt!) 

sys_stat 

System Software Int. erzeugen 

sysjnt 

VME-Bus-IRQ Level 3 erzeugen 

vme_int 

SCU General Purpose Reg. 1 

SCU General Purpose Reg. 2 

scu_gpl 

scu_gp2 
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Adresse Zugriff Bezeichnung 


Label 


$FF 8E0D R/W 


$FF 8E0F R 


$FF 8E21 R/W 


VME-Bus Int. Mask-Register vme_mask 

WWVW- (Byte) 

L 

IRQl v. VME-Bus (l=aktiviert) 

— _IRQ2 v. VME-Bus (Inaktiviert) 

-_IRQ3 / Soft-Int. (Inaktiviert) 

-_1RQ4 v. VME-Bus (l=aktiviert) 

-JRQ5 / SCC-Int. (Inaktiviert) 

-_IRQ6 / MFP-Int. (Inaktiviert) 

_IRQ7 v. VME-Bus (Inaktiviert) 

VME-Bus Int. Status-Register vme_stat 

Bitbelegung wie vor. Gesetzte Bits stellen Interrupt¬ 
anforderungen dar. (Vor “vme_mask” auslesen, da Lese¬ 
zugriff auf “vme„mask” IRQs zurücksetzt!) 

MEGA STE Cache + Taktctrl. (Byte) ste_ctl 

Die unteren beiden Bits kontrollieren die Taktfrequenz 
und den Cache-Speicher. 


Joystickports beim STE 


Adresse; 
$FF 3288 


ßit-Nr,! 


rr 

i m i irr 

i, 131 iiziei 



-'Button-Hr 


Inhalt! 

Zustand der Fipe-Buttons 
für Joysticks/Paddies 

tLog. 8 = Button betätigt'3 


Adresse; Blt-Hr.i 

15 14 (3 IS II te 3 8 7 6 5 4 3 2 . \ 0 

«FF 5202 j»|ti4-|»|^l»l4-l»«»likl»kl^FFl 

**-1--1-''-1--5-' 

Stick 3 Stick 1 Stick 2 Stick 0 


Inhalt! 

Ri chturigs i nf ornat i orten 
der Joysticks 0-3 

CLog. 8 - Stick betätigt»! 


Abb. M.5: Die Adressen der neuen Joystickports 


Adresse 

Label 

Inhalt 

$FF 9220 
SFF 9222 

XPEN 

YPEN 

X-Position des Lightpens 
Y-Position des Lightpens 
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Adresse 

Label 

Inhalt 

$FF 9210 

PADDLO 

Position des Paddle 0 

SFF9212 

PADDLl 

Position des Paddle 1 

SFF9214 

PADDL2 

Position des Paddle 2 

$FF 9216 

PADDL3 

Position des Paddle 3 


Multifunktionsbaustein MFP MC68901 

Dieser Chip ist in allen Maschinen vorhanden, jedoch zum Teil geringe Abweichungen bei 
der Belegung der GPIP-Anschlüsse! 

Alle Register sind mit Bytezugriffen zu erreichen. 

Adresse Zugriff Bezeichnung Labei 


SFFFA01 RAV 


ct 


GPIP-Data-Register gpip 

(Meldeleitungen, interruptfähig) 

* i 11 i i M i 

BUSY von par. Port (Drucker) 

RS 232 Data Carrier Detect (DCD) 

RS 232 Clear To Send (CTS) 

GPU Done (nicht TT!) 

CLKDIR (nur TT!) 

IRQ von Tastatur-/ MIDI-ACIA 
INT von FDC/ACSI-Bus 
RS 232 Ring Indicator (RI) 

Monochrome Monitor Detect 
XORED m. Frame-Ende-Signal (STE/TT) 


$FF FA03 R/W Active-Edge-Register aer 

Bitbelegung wie bei “gpip”! 

Interruptauslösung bei 
l=steig., 0-fall. Flanke 

$FF FA05 R/W Data-Direction-Register ddr 

Bitbelegung wie bei “gpip”! 

Signalrichtung für GPIP-Port 
1 = Out, 0 = In 
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Adresse Zugriff Bezeichnung 


Label 


$FF FA07 R/W 


Interrupt-Enable-Register A iera 

EEEEEEEE 



Timer B (Display enable Signal) 
XMIT Error (RS 232) 

XMIT Buffer empty (RS 232) 

RCV Error (RS 232) 

RCV Buffer full (RS 232) 

Timer A (BUSY-Signal bei ST) 
Timer A (Frame-Ende bei TT/STE) 
Port 16 (RS 232 Ring Indicator) 
Port 17 (Monochr.-Monitor Detect) 


$FF FA09 RAV 


Interrupt-Enable-Register B ierb 

EEEEEEEE 



Port 10 (BUSY v. par. Schnittst.) 
Port II (RS 232 Data Carrier Detect) 
Port 12 (RS 232 Clear To Send) 

Port 13 (GPU done, nicht TT!) 

Timer D (Baudraten-Gen. RS 232) 
Timer C (200 Hz Systemtakt) 

Port 14 (IRQ Tastatur-/ MIDI-ACIA) 
Port 15 (IRQ von FDC/ACSI-Bus) 


$FF FAOB 

RAV 

Interrupt-Pending-Register A 

(Bitbelegung siehe “iera”) 

ipra 

$FF FAOD 

R/W 

Interrupt-Pending-Register B 

(Bitbelegung siehe “ierb”) 

iprb 

$FF FAOF 

RAV 

Interrupt-In-Service-Register A 

(Bitbelegung siehe “iera”) 

isra 

$FF FA 11 

RAV 

Interrupt-In-Service-Register B 

(Bitbelegung siehe “ierb”) 

isrb 

$FF FA 13 

RAV 

Interrupt-Mask-Register A 

(Bitbelegung siehe “iera”) 

imra 
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Adresse 

Zugriff 

Bezeichnung 

Label 

$FF FA 15 

RAV 

Interrupt-Mask-Register B 

(Bitbelegung siehe “ierb”) 

imrb 

$FF FA17 

RAV 

Interrupt-Vektor-Register 

VWVS— 

vr 


End-of-Interrupt-Modus 
High-Nibble der Vektomummer 

$FF FA 19 RAV Timer-A-Ctl.-Reg. tacr 

Bei ST wird Timer A-Eingang 
vom BUSY-Anschluß angesteuert. 

Bei TT/STE wird Timer A-Eingang 
mit Frame-Ende-Signal des DMA-Sound- 
Moduls angesteuert. 

Bitbelegung wie bei Timer-B-Ctl.-Reg.! 



SFFFAIB RAV Timer-B-Ctl.-Reg. tbcr 

-RCCCC (Display Enable-Signal) 

j | Modus Vorteiler 

0000 Stop 

0001 Delay 4 

0010 Delay 10 

0011 Delay 16 

0100 Delay 50 

0101 Delay 64 

0110 Delay 100 

0111 Delay 200 

1000 Ereignis - 

1001 Pulsbreite 4 

1010 Pulsbreite 10 

1011 Pulsbreite 16 

1100 Pulsbreite 50 

1101 Pulsbreite 64 

1110 Pulsbreite 100 

1111 Pulsbreite 200 


Timer Ausgang auf Low 
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Adresse Zugriff Bezeichnung 


Label 


$FF FAID R/W 


Timer: 

$FF FA1F R/W 
$FF FA21 R/W 
$FF FA23 R/W 
SFFFA25 R/W 

$FF FA27 R/W 

SFFFA29 R/W 


Timer C+D Control Reg. tcdcr 

-CCC-DDD 

(C: 200Hz-System Takt) 

(D: Baudrate für RS232 des MFP) 


Modus Vorteiler 


000-000- 

— STOP 

- 

001-001- 

— Delay 

4 

010-010 — 

— Delay 

10 

011-011 — 

— Delay 

16 

100-100 — 

— Delay 

50 

101-101 — 

— Delay 

64 

110-110 — 

— Delay 

100 

111-111 — 

— Delay 

200 

(C) (D) 




(Takt=2,4576 MHz) 


Timer A Data Register tadr 

Timer B Data Register tbdr 

Timer C Data Register tcdr 

Timer D Data Register tddr 


Sync.-Character-Register 


scr 


USART-Control-Register ucr 

ccccccc- 

1 -l=Even-, 0=Odd-Parity 

Parity Enable 


II 

Start 

Stop 

Modus 

00 — 

— 0 

0 

Synchron 

01 — 

— l 

1 

Asynchron 

io -— 

— 1 

1,5 

Asynchron 

11 — 

— 1 

2 

Asynchron 


I I Wortlänge in Bits 

00 8 

01 7 

10 6 

II 5 

- Clock Mode (l=Clk/l6,0=Clk) 
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Adresse Zugriff Bezeichnung Label 

$FF FA2B R/W Receiver-Status-Register rsr 

ssssssss 

II 

1 — Receiver Enable 
— Synchronous Strip Enable 
—- Match bzw. Character in progress 
—— Found/Search bzw. Break 

' -Frame Error 

- Parity Error 

-—- Overrun Error 

—-Buffer Full 

$FF FA2D RAV Transmitter-Status-Register tsr 

SSSSSSSS 

I— Transmitter Enable 

Sender-Ausgangsleitung 
00 — Hochohmig 

$FF FA2D RAV Transmitter-Status-Register tsr 

SSSSSSSS 

Sender-Ausgangsleitung 
Low-Pegel 
High-Pegel 
Schleife 

Break senden 
Senden beendet 
Auto Tumaround 
Underrun Error 
Sendepuffer leer 

$FF FA2F RAV USART-Data-Register udr 

(Lesen holt Byte aus Empfangspuffer) 

(Schreiben bringt Byte in Sendepuffer) 
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Floating Point Processor MC68881 (SFP004) 

Die Register des Floating-Point-Processor-Adapters (SFP004) sind im MEGA-ST(E) ab 
Adresse $FF FA40 zu finden! Nähere Infonnationen zu diesen Hardware-Registern finden Sie 
im Anhang im Kapitel “Der Coprozessor MC68881 im MEGA ST(E)”. 


Adresse 

Zugriff 

Bezeichnung 


Label 

$FF FA40 

R 

Response-Register 

(Word) 

FPstat 

SFFFA42 

W 

Control-Register 

(Word) 

FPctl 

$FF FA44 

R 

Save-Register 

(Word) 

FPsave 

$FF FA46 

R/W 

Restore-Register 

(Word) 

FPrestor 

$FF FA48 

? 

(Reserviert!) 



$FF FA4A 

W 

Command-Register 

(Word) 

FPcmd 

$FF FA4C 

? 

(Reserviert!) 



$FF FA4E 

R 

Condition-Code-Reg. 

(Word) 

FPccr 

SFFFA50 

R/W 

Operanden-Register 

(Long!) 

FPop 

$FF FA54 

R 

Register Select 

(Word) 

FPselct 

$FF FA56 

? 

(Reserviert!) 



$FF FA58 

W 

Instruction Address 

(Long!) 

FPiadr 

$FF FA5C 

? 

(Reserviert!) 

(Long!) 


TT-MFP MC68901 



Dieser Chip ist nur im TT zu finden! Alle Register sind mit Bytezugriffen zu erreichen. 

Adresse 

Zugriff 

Bezeichnung 


Label 


SFFFA81 R/W 


GPIP-Data-Register GPIP_TT 

IIIIIIII (Meldeleitungen, interruptfähig) 


Auf Pfostenstecker geführt und für 
künftige Erweiterungen reserviert! 

IRQ (Low) von SCC-DMA-Controller 
Ring Indicator von MODEM 2-Buchse 
Von P.34 des internen Disk-Drives 
Busfehler (Low) von SCSI-DMA-Ctl. 
IRQ (Low) von TT-Uhrenchip 
IRQ (High) von SCSI-Controller 
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Adresse Zugriff Bezeichnung 


Label 


SFFFA83 R/W 


$FF FA85 RAV 


$FF FA87 RAV 


$FF FA89 RAV 


SFFFA8B RAV 


Active-Edge-Register AER_TT 

Bitbelegung wie bei “GPIP_TT”! 

Interruptauslösung bei 
1 = steig., 0 = fall. Flanke 

Data-Direction-Register DDRJTT 

Bitbelegung wie bei “GPIP_TT”! 

Signalrichtung für GPIP-Port 
1 = Out, 0 = In 


Interrupt-Enable-Register A IERAJIT 

EEEEEEEE 

^- Timer B (Display enable Signal) 

- XMIT Error (RS 232) 

-- XMIT Buffer empty (RS 232) 

L—- RCV Error (RS 232) 

L-RCV Buffer full (RS 232) 

L-• Timer A 

—--Port 16 (IRQ von Uhrenchip) 

--Port 17 (IRQ von SCSI-Controller) 

Interrupt-Enable-Register B EERB_TT 

EEEEEEEE 

I- PortIO 

- Port II 

-— Port 12 (IRQ v. SCC-DMA-Controller) 

- Port 13 (RI von MODEM 2-Buchse) 

I-Timer D (Baudr.-Gen. für SERIAL 1) 

-- Timer c (Takt für SCC-Kanal B) 

- Port 14 (P.34 von int. Floppy-Disk) 

-— Port 15 (Busfehler SCSI-DMA-Chip) 

Interrupt-Pending-Register A IPRAJTT 

(Bitbelegung siehe “IERA_TT”) 


$FF FA8D RAV 


Interrupt-Pending-Register B 

(Bitbelegung siehe “IERBJ1T”) 


IPRB_TT 
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Adresse 

Zugriff 

Bezeichnung 

Label 

SFF FA8F 

RAV 

Interrupt-In-Service-Register A 

(Bitbelegung siehe “EERA_TT”) 

ISRAJTT 

$FF FA91 

RAV 

Interrupt-In-Service-Register B 

(Bitbelegung siehe “IERB_TT”) 

ISRB_TT 

$FF FA93 

RAV 

Interrupt-Mask-Register A 

(Bitbelegung siehe “1ERA_TT”) 

IMRA_TT 

$FF FA95 

RAV 

Interrupt-Mask-Register B 

(Bitbelegung siehe “IERB_TT”) 

IMRBJTT 

$FF FA97 

RAV 

Interrupt-Vektor-Register 

VWVS- 

VR_TT 


End-of-Interrupt-Modus 
High-Nibble der Vektomummer 


$FF FA99 

RAV 

Timer-A-CtL-Reg. 

Bitbelegung wie bei Timer-B-Ctl.-Reg.! 

TACR_TT 

SFF FA9B 

RAV 

Timer-B-Ctl.-Reg. 

-RCCCC (Display Enable-Signal) 

TBCRJTT 


| | | | Modus Vorteiler 

0000- Stop - 

0001-Delay 4 

0010-Delay 10 

0011-Delay 16 

0100-Delay 50 

0101-Delay 64 

0110-Delay 100 

0111-Delay 200 

1000 - Ereignis - 

1001 -Pulsbreite 4 

1010 -Pulsbreite 10 

1011 -Pulsbreite 16 

1100 -Pulsbreite 50 

1101 - Pulsbreite 64 

1110- Pulsbreite 100 


1111-Pulsbreite 200 

- Timer-Ausgang auf Low 
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Adresse Zugriff Bezeichnung 


Label 


SFFFA9D R/W Timer C+D Control Reg. TCDCR_TT 

-CCC-DDD 

(C: Takt für SCC-Kanal B) 

(D: Baudrate für SERIAL 1) 


Modus Vorteiler 




000-000-STOP 

- 

(Takt-2,4576 MHz) 



001-001-Delay 

4 




010-010-Delay 

10 




011-011-Delay 

16 




100-100 -Delay 

50 




101-101-Delay 

64 




110-110-Delay 

100 




111-111-Delay 

200 



Timer: 

(C) (D) 



$FF FA9F 

R/W 

Timer A Data Register 


TADR_TT 

SFFFAAl 

RAN' 

Timer B Data Register 


TBDRJTT 

$FF FAA3 

RAV 

Timer C Data Register 


TCDRJTT 

$FF FAA5 

RAV 

Timer D Data Register 


TDDRJTT 

$FF FAA7 

RAV 

Sync.-Character-Register 


SCR_TT 

$FF FAA9 

RAV 

USART-Control-Register 


UCR_TT 



ccccccc- 




l=Even~, 0=Odd-Parity 
Parity Enable 



II 

Start Stop 

Modus 

00- 

— 0 0 

Synchron 

01 - 

— 1 1 

Asynchron 

10 — 

-1 1,5 

Asynchron 

11 — 

—- 1 2 

Asynchron 


| | Wortlänge in Bits 

00-8 

01- 7 

10-6 

11-- 5 

-Clock Mode (l=Clk/16, 0=Clk) 
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$FF FAAD RAV Transmitter-Status-Register TSR_TT 

ssssssss 

I- Transmitter Enable 

Sender-Ausgangsleitung 
00 Hochohmig 

01 Low-Pegel 

10 High-Pegei 

11 Schleife 

- Break senden 

- Senden beendet 

-Auto Tumaround 

-Underrun Error 

- Sendepuffer leer 

IFFFAAF RAV USART-Data-Register UDR_TT 

(Lesen holt Byte aus Empfangspuffer) 

(Schreiben bringt Byte in Sendepuffer) 
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Tastatur-ACIA 

Adresse Zugriff Bezeichnung Label 


$FF FCOO R 


ACIA-Statusregister (Byte) 

ssssssss 



Receive Data Register Full 
Transmit Data Register Empty 
Data Carrier Detect 
Clear To Send 
Framing Error 
Receiver Overrun 
Parity Error 
Interrupt Request 


keyctl 


$FFFC01 W ACIA-Steuerregister (Byte) keyctl 

cccccccc 

| | (ACIA-Betriebsart/Vorteilerfaktor) 

00 — Baudrate=Taktfrequenz 
01 — Baudrate=Taktfrequenz/16 

10 — Baudrate=Taktfrequenz/64 

11 — ACIA Reset 


11 

Bits/Wort 

Parity 

Stopbits 

000 

7 

gerade 

2 

001 - 

7 

ungerade 

2 

010- 

7 

gerade 

1 

011 - 

7 

ungerade 

1 

100- 

8 

- 

2 

101 - 

8 

~ 

1 

110 - 

8 

gerade 

1 

111- 

8 

ungerade 

1 


00- RTSaufLow, TxINT gesperrt 

01- RTS auf Low, TxINT freigeben 

10 - RTS auf High, TxINT gesperrt 

11 - RTSaufLow, TxINT gesperrt 

“Break” senden 

■... RxINT freigeben 
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Adresse 

Zugriff 

Bezeichnung 

Label 

$FF FC02 RAV 

MIDI-ACIA 

ACIA-DATA-Register (Byte) 

(READ = Empfangsdaten) 

(WRITE= Sendedaten) 

keybd 

Adresse 

Zugriff 

Bezeichnung 

Label 

$FF FC04 

R 

ACIA-Statusregister (Byte) 

(siehe Tastatur-ACIA) 

midictl 


W 

ACIA Steuerregister (Byte) 

(siehe Tastatur-ACIA) 

midictl 

$FF FC06 

RAV 

ACIA DATA Register (Byte) 

(READ = Empfangsdaten) 

(WRITE= Sendedaten) 

midi 
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Abb.N.l: CPU-Pinbelegungen im ST/STE 
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AM>. JV.2: CPU MC 68030 im TT (PIN-GR1D-ARRAY-Format) 



Abb. N.3: CPU MC 68030 im TT (SMD-Format) 
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Abh. N.4: Die Pinbelegung des 68881/68882 im PIN-GRID-ARRAY-Format 



Abb. N.5: Pinbelegung der ST-MMU 
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Abb. N.6: Pinbelegung des ST-GLUE 



Abb. N.7: Pinbelegung des STISTE-BL1TTER 
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Abb. N.8: Pinbelegung des ST-SHIFTER 



Abb. N.9: Pinbelegung des STE-SHIFTER 
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Abb. N.10: Pinbelegung des ST/STE/TP-DMA-Chips 
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Abb. N.l 1; Pinbelegung des ST/STE/TT-PSG 
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Abb. N.12: Pinbelegung des ST-MFP und des STEITT-MP'P 
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Abb. N.J3: Pinbelegung des STISTE/TT-FDC 



Abb. N.14: Pinbelegung des STISTE/TT-ACIA 
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Abh. N.15: Pinbelegung der STE/GSTMCU 
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Abb. N.16: Pinbelegung der STEITT-rrSCU 
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Abb.N.17: Pinbelegung der TT-MCU 
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Abb. N.J8: Pinbelegung des TT/FUNNEL-Chips 
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Abb. N.21: Pinbelegung der TT-Fast-MCU 
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Abb. N.22: Pinbelegung des TT-DMAC und des TT-DCU-Chips 
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Abb. N.24: Pinbelegung des TT-Uhrenchips 
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200Hz-Timer-Interrupt 55 
40-Ordner-Fehler 180 
5380 (SCSI) 1114 
6301 (IKBD) 922 
68030 im TT 1009 

68881 1019,1022 

68882 1019 
68882-Befehle 1026 

68882-FPU, hardwaremäßige Einbindung 1020 
68882-Register 1026 
85C30 (SCC) 1135 


A 

Al (ACSI) 984 

ABC-GEM 289,534 

Abwärtszähler (MFP) 874 

Accessories, Erkennung im Startupcode 541 

Accessories, Laden der 539 

Accessory 547,607, 625 f. 

Accrued Exception Byte (AEXC) (68882) 1034 

ACFAIL (VME-Bus) 1192 

ACIA 911 

ACIA (MFP) 893 

ACIA-Betriebsweisen 912 

ACIA-Zeichenformat 913 

ACIAsimTT 1211 

ACK (ACSI) 984 

ACK (SCSI) 1077 

ACKNLG-Signal (par. Schnittstelle) 907 
Acknwldg, (SCSI) 1077 
ACSI-Bus 981 f. 

ACSI-Bus (TT/MEGA STE) 1215 f. 
ACSI-Bus-Zugriff 817 

ACSI-Bus, hardwaremäßige Realisierung des 983 
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act_pd 185 

Active-Edge-Register (TT-MFP, Adr. $FF(FF) FA83) 1064 

Active-Edge-Register, (ST-MFP, Adr. $FF FA03) 872, 875, 878, 1300 

ACCLOSE (41) 547,606, 720, 732, 739 

AC_OPEN (40) 546,594 

Address Mark-Detector (FDC) 973 

Address Modifier (VME-Bus) 1188,1193 

Address Strobe (68030) 1006 

Address Strobe (Megabus) 823 

Address Strobe (VME-Bus) 1187 

Address Translation Cache (68030) 1009, 1014 

Adreßbus (Megabus) 823 

Adreßbus, gemultiplexter 796 

Adreßbus (68030), 32-Bit- 1005 

Adreßfehler (SC) 51 

Adreßleitungen 793 

Adreßraum 794 

Adreßraum (68030) 1012 

Adreßumsetzung (68030) 1014 

AER (MFP, Adr. $FF FA03) 1300 

AER (ST-MFP, Adr. $FF FA03) 872 

AERJTT (TT-MFP, Adr. $FF(FF) FA83) 1064 

AES 337,533 

AES-Bindings 587 f. 

AES-Environment 66, 191,539, 707 
AES-Opcode, falscher 589 
AES Parameterblock 588 
AES, Initialisierung 538 
AESPB 588 
after touch (MIDI) 917 
AHDI.PRG 24 f. 

AHDI/HDX 171 
Aktionspunkt 307, 318 f., 443 
Alarm-Box 567,643 

Alarmfunktion (MEGA ST(E)-Uhrenchip) 1329 
Alarmzeitregister (TT-Uhr) 1202 f. 

Allocate meinory 251 
Allocate memory (with preference) 255 
Alpha-Cursor 482, 484 ff., 496 
ALPHA CURSOR DOWN (VDI5, 

Escape 5) 486 
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ALPHA CURSOR LEFT (VDI5, 

Escape 7) 488 

ALPHA CURSOR RIGHT (VDI 5, 

Escape 6) 487 

ALPHA CURSOR UP (VDI 5, Escape 4) 485 
Aipha-Text 483 f., 494 f. 
Altemate-Function-Code Register (68030) 1012 
Alternate RAM 182, 194, 1039,1042 
AM-Codes (VME-Bus) 1188 
AM-Detector (FDC) 973 
AM0..AM5 (VME-Bus) 1188 
Ankommender Ruf (Ring indicator (RI)) 56, 893 
Anschlußbelegung, Megabus- 821 
Anschlußkabel (Diskstation) 953 
ANSI-Standard 275 
_app 541 

APPL_BVSET (AES 16) 604,673 
APPLJBXIT (AES 19) 606 
APPL_FIND (AES 13) 599 
APPLJNIT (AES 10) 541,594 
APPL_READ (AES 11) 596,599 
APPL_TPLAY (AES 14) 601 f. 
APPL_TRECORD (AES 15) 602 
APPLJWRITE (AES 12) 597,599 
APPL_YDELD (AES 17) 605 
ap_id 542, 625 f. 

Arbeitsbereich 578 

Arbeitstakt (PSG) 859, 863 

Arbiter (VME-Bus) 1189 

Arbitrary Line ($A003) 311 

ARBITRATION-Phase (SCSI) 1078 

ARBITRATION, SCSI-Systeme ohne 1080 

Arbitrations-Bus (VME-Bus) 1185,1189 

ARC (VDI 11, GDP 2) 361 

Archiv-Bit 227,247 

ARGV-Verfahren 191 f., 256, 586 

argv[0] 192 

ARHEADER 197 

Arithmetic Processing Unit (APU) (68882) 1022 
ARROW (0) 667 
Artline 325 
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AS (68030) 1006 

AS (Megabus) 823 

AS (VME-Bus) 1187 

Aspect ratio 279 

ASSIGN.SYS 292, 330 f„ 343 

Asynchrone Steuerungsverfahren (SCC) 1136, 1155 

Asynchronous-Communications-Interface-Adaptor (ACIA) 911 

ATARI Computer System Interface (ST) 813 

ATC (68030) 1009 

ATN (SCSI) 1076 

attack velocity (MIDI) 917 

Attention (SCSI) 1076 

Auch eine prominente Zahl 42 

Auflösung 62, 121, 152,279, 1047 

Ausgabestatus 210, 216 

Ausgangsamplitude (PSG) 864 

Ausnahmebehandlung (68030) 1014 

Ausnahmevektoren 796,1010 

AUTO-Ordner 20 

Auto Tumaround (MFP-USART) 902 
Autolautsprecher 946 
Automatic-EOI-Modus (MFP) 888 f. 

_autopath ($4CA) 66 


Autovektor-Interrupt 

883, 

1008 


Autovektor-Interrupt, 

Level 

1 ($64) 

53 

Autovektor-Interrupt, 

Level 

2 ($68) 

53 

Autovektor-Interrupt, 

Level 

3 ($6C) 

53 

Autovektor-Interrupt, 

Level 

4 ($70) 

53 

Autovektor-Interrupt, 

Level 

5 ($74) 

54 

Autovektor-Interrupt, 

Level 

6 ($78) 

54 

Autovektor-Interrupt, 

Level 

7 ($7C) 

54 


AUX: 161,237 
AV-Protokoll 547 
AVEC (68030) 1008 
AY-3-8910 (PSG) 859 
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B 


Bad sector list 30, 994 
Badertscher, Ken 192 
BAR (VDI11, GDP 1) 360 
Base line 351,396, 398,401,407, 477 
BASEPAGE 186,244, 267, 586, 702 
Basisbandverfahren (SCC) 1139 
Basislinie 351, 396, 398,401, 407, 477 
Baudratengenerator (SCC) 1135, 1165 f. 
BBSY (VME-Bus) 1189,1192 
BCB 171 

BCLR (VME-Bus) 1189, 1192 
Bconin (BIOS 2) 65,83 
Bconmap (XBIOS 44) 98 
BCONMAP-Struktur 12f.,98 
Bconout (BIOS 3) 11, 84 
Bconstat (BIOS 1) 83, 85 
Bcostat (BIOS 8) 11, 86 
Bedienerführung 745 
Bedingungsabfrage-Bits (68881) 1340 
Bedingungscodes (68882) 1033 
Befehl TRAPV ($1C) 52 
Befehl, illegaler 51 
Befehlsbytes (FDC) 971 
BEG_MCTRL (3) 691 
BEGJJPDATE (1) 691 
bell_hook ($5AC) 11,71 
Benutzeroberfläche 745 f. 

BERR (68030) 1008 
BERR (Megabus) 824 
BERR (VME-Bus) 1188,1193 
Beruhigungspause, Kopf- 962 
Betriebsarten (IKBD) 923 
Betriebsarten, MIDI- 916 
Betriebssystem-ROMs 801 
Bezierkurven 288 
BG (68030) 1008 
BG (Megabus) 822 
BG0..BG3 (VME-Bus) 1189 
BGACK (68030) 1008 
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BGACK (BUTTER) 857 

BGACK (Megabus) 822,825 

BGI (BUTTER) 857 

BGKI (BUTTER) 857 

BGM-Partition 28 

BGO (BUTTER) 857 

BGO (Megabus) 822,824 

Bildpunkt 833 

Bildschirm 149,219 

Bildschirmmanager 536 f„ 599 

Bildschirmspeicher 62 f., 133, 139, 152 

Bildschirmspeicher (ST/STE) 832 

Bildschirmspeicher (TT) 1047 

Bildschirmtreiber 300, 331, 337 

Bildschirmzeilenzähler, Timer B (MFP) als 878, 1065 

Bildwiederholfrequenz, ST(E)-Mono-chrom- 827 

Binäres Realzahl-Format (68882) 1023 

Binary Real Data Format (68882) 1023 

Bioskeys (XBIOS 24) 100 

Biphase Mark-/Space-Verf. (SCC) 1140 

Bit-Block-Transfer 789, 842 f. 

Bit-Image 563 
Bit-Planes (Bit-Ebenen) 834 
BITBLK 563 
BITBLT 315 

Bitbit (Bit Block Transfer) ($A007) 314 

BitBlt-Funktion 841 

Bitmap-Zeichensätze 289 

Bitorientierte Steuerungsverfahren (SCC) 1138 

Bitsynchronismus 1136 

Bitwanderungen (Disk) 969 

BLACK (1) 558 

Blitmode (XBIOS 64) 101 

Blitter 55, 101, 789, 841, 845, 1363 

Blitter (STE) 1285 

Blitter-TOS 802 

Blitter, Einbindung in ST/STE-Hardware 856 
Blitter, Registerzugriffe 843 
Block-Anzahl (ACSI) 991 
Block-Nummer (ACSI) 990 
Blockadresse, Log. 1085, 1088 
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Blockgröße (SCSI) 1088 
Blockmodus (ACSI) 987 
Blockschaltbild des ST 791 
BLUE (4) 558 

Bömbchen 51, 54, 58, 96, 252, 304 

Bombengirlanden 57 

_bootdev ($446) 61, 539, 708 

Bootsektor 15,17, 38,64,140, 162 

Bootvorgang 44 

BPB 14,88,162 

BR (68030) 1008 

BR (Megabus) 824 

BR0. .BR3 (VME-Bus) 1189,1192 

Braner, Moshe 82 

BREAK (ACIA) 913 

BREAK (SCC) 1158 

BREAK-Code (IKBD) 931 

Break-Point 51 

Break-Zeichen (ser. Datenübertragung) 899 

BSS 186 

BSY (SCSI) 1076 

_bufl($4B2) 66 

Bug bei READ TRACK (FDC) 973 

Bug im ACSI-DMA-Baustein 1000 

Bug im Hostadapter der SH204 998 

BuginRsconf 903 

Burst-fill-Modus (68030) 1007,1012 

Burst-mode (68030) 1044 

Bus-Arbitration (VME-Bus) 1190 

Bus-Ausnahmesteuerung (68030) 1008 

Bus Busy (VME-Bus) 1189 

Bus Clear (VME-Bus) 1189 

Bus Error (68030) 1008 

Bus Error, (Megabus) 824 

Bus-Fahrplan (ACSI) 984 

BUS FREE-Phase (SCSI) 1078 

Bus Grant (68030) 1008 

Bus Grant (Megabus) 822 

Bus Grant (VME-Bus) 1189 

Bus Grant Acknowledge (68030) 1008 

Bus Grant Acknowledge (Megabus) 822, 825 
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Bus Grant Out (Megabus) 822, 824 
Bus Interface Unit (68882) 1022 
Bus-Phasen (ACSI) 984 
Bus-Phasen (SCSI) 1077 
Bus Request (68030) 1008 
Bus Request (Megabus) 821, 824 
Bus Request (VME-Bus) 1189 
Bus-Steuersignale (68030) 1005 
Busbetriebsarten (68030) 1003 
Busfehler ($8) 51 

Busfehler von SCSI-DMA-ControIler (TT) 1064 
Busmaster, Megabus- 821 
BUS Y (SCSI) 1076 

BUSY-Bit (BUTTER, Adr. $FF 8A3C) 855 
BUSY-Leitung (par. Schnittstelle) 907 
BUSY-Leitung an MFP 869,875 
BUSYBEE (2) 667 

Buszuteilung (68030), Steuersignale für die 1008 
Buszyklus (68030) 1005,1012 
Buszyklus, (Megabus) 822 
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c 

C/D (SCSI) 1077 
Cache (68030) 1012 

Cache Address Register (CAAR) (68030) 1013 

Cache Burst Acknowledge (68030) 1007 

Cache Burst Request (68030) 1007 

Cache Control Register (CACR) (68030) 1013 

Cache Disable (68030) 1009 

Cache Inhibit (68030) 1007 

Cache, Mega STE 1368 

Cache-Prinzip 1012 

Cache-Speicher (RAM) 1044 

Cache-Steuersignale (68030) 1007 

CACHENNN.PRG 171 

Carrier detect 55 

Cartridge-Adreßraum 805 

Cartridge-Anschlusses, Belegung des 807 

Cartridge-Application-Header 810 

Cartridge-Konzept 807 

Cartridge-Port 806 

Cartridge-Programme 806, 809 ff., 1045 
Cartridge-ROM 806 
Cartridge-Slot 807 

Cartridge, Schaltung für ein 128 KByte- 808 
Cartridgeport beim TT 1045 
CAS 796 

Cauxin (GEMDOS 3) 205 
Cauxis (GEMDOS 18) 206 
Cauxos (GEMDOS 19) 207 
Cauxout (GEMDOS 4) 208 
CA_SIZE (Cartridge) 812 
CBACK (68030) 1007 
CBREQ (68030) 1007 
Cconin (GEMDOS 1) 209,219 
Cconis (GEMDOS 11) 210 
Cconos (GEMDOS 16) 210 
Cconout (GEMDOS 2) 211,219 
Cconrs (GEMDOS 10) 212 
Cconws (GEMDOS 9) 214 
CD-ROM 981 
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CDB (SCSI) 1086,1088 
CD1S (68030) 1009 
CELL ARRAY (VDI 10) 301,355 
Centronics-Interface/-Timing 907 

Centronics-Schnittstelle 55, 69, 83 f„ 86, 154,161,216, 861, 907 
CHANGE GEM VDI FILE NAME 
(VDI 5, Escape 100) 528 

CHECK CONDITION-Status (SCSI) 1083,1085, 1090 
Check Status of Standard AUX: input 
206 

Check Status of Standard AUX: output 207 

Check Status of Standard input 210 

Check Status of Standard output 210 

Check Status of Standard PRN: 216 

CHECKED (0x0004) 558,663 

Chip Select (ACSI) 984 

CHK-Befehl ($18) 52 

CHN (68030) 1007 

CIOUT (68030) 1007 

CIRCLE(VDIll.GDP4) 365 

CLEAR DISPLAY LIST (VDI 5, 

Escape 22) 503 
Clear screen (and home Cursor) 

(VT52 ESC E) 8 

Clear to end of line (VT52 ESC K) 8 

Clear to send (CTS) 55, 893 

Clear To Send-Bit (ACIA) 914 

CLEAR WORKSTATION (VDI 3) 340,501, 503 

Clipboard 572, 670 ff., 751 

Clipping 280,285, 346, 565, 631,638 

CLK (Megabus) 822 

CLOSE (0x0002) 678,693 

Close file 228 

CLOSE VIRTUAL SCREEN WORKSTATION (VDI 101) 339 
CLOSE WORKSTATION (VDI 2) 336 
Cluster 14, 88, 162 
CLUT 283 

_cmdload ($482) 42, 64 
Cnecin (GEMDOS 8) 215 

Codierungsverfahren für Datensignale (SCC) 1139,1162 
Color indirection 835 
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Color-Lookup-Table 283 
colorptr ($45A) 48, 63 
colorX (TT, ab Adr. $FF(FF) 8240) 1056 
Command-Bytes (ACSI) 999 
Command-Code (SCSI) 1087 
Command Descriptor Block (ACSI) 989 
Command Descriptor Block (CDB) (SCSI) 1086 
Command line 244 
Command-Phase (ACSI) 984,986 
Command-Phase (SCSI) 1080 
COMMAND.PRG 64 
Common-Commands (MIDI) 918 
CON: 64, 83 ff., 161,237 
conterm ($484) 9, 11, 64, 72, 83, 209 
CONTOUR FILL (VDI 103) 357 
Control Byte (ACSI) 991 
Control Byte (SCSI) 1088 
Control/Data (SCSI) 1077 
Controller (ACSI) 982 
Controller-Access-Register 
(Adr. $FF 8604) 817,987,989 
Controller execute (IKBD $22) 941 
Controller Read/Write (FDC/ACSI-DMA) 816 
Conversion Unit (CU) (68882) 1022 
con_state ($4A8) 9, 65 
Cookie Jar 72, 743 
COORDINATE WINDOW 
(VDI 5, Escape 99, Opcode 1) 526 
Coprocessor Interface Register (68882) 1026 
Coprozessor (68881) 1331 
Coprozessor (68882) 1019 
Coprozessor-Befehlswort (68881) 1334,1336 
Coprozessor-Interface-Register (68882) 1019 
Coprozessor-Interface-Register (CIR) (68881) 1331 
Coprozessor-Operationen (68030) 1005 
Coprozessor-Protokoll (68881) 1333 
Coprozessorbefehle (68882) 1026 
Copy raster form ($A00E) 319 
COPY RASTER, OPAQUE (VDI 109) 415 
COPY RASTER, TRANSPARENT 
(VDI 121) 418 
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CP/M 275 

CP/M68K 159 

Cpmos (GEMDOS 17) 216 f. 

Cpmout (GEMDOS 5) 217 
_CPU 78 

CPU address space (68030) 1005 
CPU'Root-Pointer (68030) 1016 
CPX 717 ff. 

CPXHEAD 719 

CPXINFO 717,724,726 

cpx_button 731 

cpx_call 728 

cpx_close 732 

cpx_draw 729 

cpx_hook 732 

cpxjnit 727 

cpxjkey 730 

cpx_ml 731 

cpx_m2 731 

CPX_Save 742 

cpx_timer 730 

cpx_wmove 729 

Crawcin (GEMDOS 7) 215, 218 

Crawio (GEMDOS 6) 219 

CRC-Bytes (Disk) 948 

CRC-Prüflogik (SCC) 1144 

CRC-Verfahren (Datenübertragung) 1138 

CREATE BASEPAGE 258 

CREATE BASEPAGE, RESPECTING PRGFLAGS 260 

Create directory 220 

Create file 229 

Critical error handler 704 

criticret ($48A) 65 

CROSSED (0x0002) 558,663 

CRP (68030) 1016 

crys_if 590 

CS(ACSI) 984 

CTRL-Codes 212,215 

CTS(ACIA) 914 

CTS (Clear to send) 55, 893 

CT_KEY (53) 547,726,739 
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CT_MOVE (51) 547 
CT_NEWTOP (52) 547 
CTUPDATE(50) 547 
Cursconf (XBIOS 21) 102 
Cursor backward (VT52 ESC D) 7 
Cursor down (VT52 ESC B) 7 
Cursor forward (VT52 ESC C) 7 
Cursor-Position 65 
Cursor up (VT52 ESC A) 7 
CimS JBLINK (2) 102 
CURSGETRATE (5) 102 
CURS_HIDE (0) 102 
CURS_NOBLINK (3) 102 
CURS_SETRATE (4) 102 
CURS_SHOW (1) 102 
Custom-Chips, ST- 788 
CYAN (5) 558 

Cyclic Redundancy Checking (Disk) 949 
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D 

Daisy-Chaining (Megabus) 822 
Daisy-Chaining (VME-Bus) 1190 
Das Boot 20 
DATA 186 

Data-address-mark (DAM) (Disk) 948,968 
Data Buffer Enable (68030) 1006 
Data Carrier Detect 893, 913 f. 

Data Carrier Detect (DCD, ACIA) 55 
Data-Direction-Register (TT-MFP, 

Adr. $FF(FF) FA85) 1064 
Data-In/-Out-Phase (ACSI) 988 
DATA IN/OUT-Phase (SCSI) 1080,1082 
Data Request (FDC) 968 
Data Strobe (68030) 1006 
Data Terminal Ready (SCC) 1158 
Data Terminal Ready (ST-MFP-USART) 893 
Data Transfer ACKnowledge (Megabus) 823 
Data Transfer ACKnowledge (VME-Bus) 1188 
Data Transfer and Size Acknowledge (68030) 1006 
Datei-Attribut 165, 227 
Datei-Attribut, “hidden” 227, 229, 247, 652 
Datei-Attribut, Archiv-Bit 227, 247 
Datei-Attribut, Diskettenname 247 
Datei, versteckte 227, 229, 247, 652 
Dateiauswahlbox 574, 673, 675, 753 
Dateibezeichnungen 159 
Dateiende 209, 212 
Dateikennung 173,231 
Dateiname 159 

Dateinamen, erlaubte Zeichen 160 
Dateisystem 159 

Daten Transfer Bus (VME-Bus) 1185, 1187 
Datenaustausch (Computer <-> Disk) 949 
Datenbus 793, 796 
Datenbus (68030), 32-Bit- 1005 
Datenbus (Megabus) 823 
Datenbus (SCSI) 1077 
Datenbus (TT-ROM), 32-Bit- 1037 
Datenbus (TT), 64-Bit-Memory- 1039 
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Datenbytes (MIDI) 917 

Datenendeinrichtung (DEE) 892 

Datenpaket (IKBD) 935 

Datenrichtungsregister (IKBD) 929 

Datenseparator (FDC) 947, 956 

Datenübermittlungs-Steuerungsverfahren (SCC) 1135 

Datenübertragung (ACSI) 999 

Datenübertragung (par. Schnittstelle) 907 

Datenübertragung (SCC) 1135 

Datenübertragung mit ACIAs, serielle 911 

Datenübertragung vom IKBD stoppen 938 

Datenübertragung, asynchrone 892 

Datenübertragung, interruptgesteuerte 895 

Datenübertragung, MIDI- 917 

Datenübertragung, synchrone 891 

Datenübertragungsrate (IKBD) 927 

Datenübertragungsrate (Keyboard/Midi-ACIA) 911 

Datenübertragungsrate (SCC) 1135 

Datenübertragungsrate (ST-MFP-USART) 894 

Datenübertragungsrate (STE-MICRO-WIRE(TM)-Interface) 1309 

Datenübertragungsraten (ser. Schnittstelle) 903 

Datum 122,153,231 

dbaseh (Adr. $FF 8201) 839,1055, 1315 

dbasel (Adr. $FF 8203) 839,1055,1316 

dbaselow (Adr. $FF 820C) 1055,1316 

DBEN (68030) 1006 

DCD (Data carrier detect) 893, 913 f. 

Dcreate (GEMDOS 57) 220 

Ddelete (GEMDOS 58) 221 

DDR (ST-MFP, Adr. $FF FA05) 872 

DDR . TT (TT-MFP, Adr. $FF(FF) FA85) 1064 

DEFAULT (0x0002) 556 

Defect Descriptor (SCSI) 1098 

Defektliste (SCSI) 1096, 1098,1101 

defshiftmd ($44A) 48,62 

Delay Mode (MFP-Timer) 874 

Delete directory 221 

Delete file 232 

Delete line (VT52 ESC M) 8 

Density (FDC) 950 

Descriptor type (DT) (68030) 1016 
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Desktop 483,599 
Desktop-Fenster 580 
DESKTOP.INF 539,705 

Destination-Adress-Register (BUTTER, Adr. $FF 8A32) 849 

Destination-X-Increment-Register (BLITTER, Adr. $FF 8A2E) 848 

Destination-Y-Increment-Register (BLITTER, Adr. $FF 8A30) 848 

Device-Nummmer (ACSI) 990 

Dezimal Gepacktes Realzahl-Format (68882) 1025 

Dfree (GEMDOS 54) 222 

Dgetdrv (GEMDOS 25) 161,223 

Dgetpath (GEMDOS 71) 161,224 

DIABLO 11,183 

Dialogbox 753,764,776 

Die Zahl schlechthin 17 

Digital Phase Locked Loop-Einheit (SCC) 1135,1166 
Digital/Analog-Wandler (STE) 1294 
DIP-Switch 80 
DIR 164 

DIRECT ALPHA CURSOR ADDRESS (VDI5, Escape 11) 492 

Direct Memory Access 813 

Disable Cursor (VT52 ESC 1) 9 

Disable joysticks (IKBD $1A) 940 

Disable mouse(IKBD $12) 938 

DISABLE OR ENABLE FILM EXPOSURE FOR FRAME PREVIEW (VDI 5, Escape 
93) 520 

DISABLED (0x0008) 558,652, 663 
Discard at end of line (VT52 ESC w) 9 
diskctl (Adr. $FF 8604) 817 f„ 977, 999 
Diskette 945 
Diskettenformat 17 
Diskettenlaufwerk 66,953 
Diskettenname 227,229, 247 
Diskettenwechsel 21, 64, 92, 166,953, 1114 
DISKINFO 222 
Disklaufwerk, 3,5-Zoll- 945 
Disklaufwerk, Anschlüsse am 949 
Disklaufwerk, Schaltbild 954 
Dispatcher 54 f., 299, 536 
Display-List 341 
DIV 52 

Division durch Null ($14) 52 



Stichwortverzeichnis 


1421 


DMA 813 

DMA-Base- und Counter-Register 
(ab Adr. $FF 8609) 817, 976, 999 
DMA-Baustein (BUTTER) 842 
DMA-Betrieb (FDC/ACSI-DMA) 817 
DMA-Datenbus 814 
DMA-Datentransfer (ACSI) 984 
DMA-Datentransport-Richtung, Bit für die 819 
DMA-Einheit 789, 813 f., 981, 1352 
DMA-Einheit (FDC) 957,974,976 
DMA-Einheit (TT-SCSI) 1124 

DMA-Mode-Register (Adr. $FF 8606) 819, 977, 987, 989, 999 
DMA-Operation 818,1000 
DMA-Sector-Counter-Register 
(Adr. $FF 8604) 999 
DMA-Sound 1212,1286, 1296,1361 
DMA-Sound, Beispiellisting 1301 
DMA-Sound, Schaltungsauszug 1307 
DMA-Status-Register (Adr. $FF 8606) 818,978 
dmahigh, Adr. $EF 8609 817,976 
dmalow, Adr. $FF 860D 817, 976 
dmamid, Adr. $FF 860B 817, 976 
DMAread (XBIOS 42) 23,103 
DMAwrite (XBIOS 43) 23,104 
DNARROW (0x0080) 678,693 
Doppelklick 756 
Dosound (XBIOS 32) 105 
DOSTIME 231 

Double Real (68882) 1023, 1027 
dpi 279 

DPLL (SCC) 1135, 1145,1166 
Draw sprite ($A0OD) 319 
DRAW3D (0x0080) 558 
Drive select (FDC) 951,953,955,975 
Drive select (TT-PSG) 1211 
Drive-Select-Leitung (PSG) 866 
Drive Status Block (DSB) 959 
Drive-Status-Block (TT) 1214 
Drop-Down-Menü 748 f., 766 
DRQ (ACSI) 984 
Drucker 154, 217 
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Drucker-Timeout 216 
Druckertreiber 321,331,341 
_drvbits ($4C2) 14,66 
Drvmap (BIOS 10) 14,87 
DS(68030) 1006 
DS0/DS1 (VME-Bus) 1188 
DSACKO, DSACK1 (68030) 1006 
DSACK0, DSACK1 (68882) 1019 
Dsetdrv (GEMDOS 14) 87,161, 225 
Dsetpath (GEMDOS 59) 161,226 
_dskbufp ($4C6) 66 

Dst_Addr (BUTTER, Adr, $FF 8A32) 849 

Dst_Xinc (BUTTER, Adr. $FF 8A2E) 848 

Dst_Yinc (BLITTER, Adr. $FFF 8A30) 848 

DTA 186,235,244,246 

DTACK (Megabus) 824 

DTACK (VME-Bus) 1188 

DTR (Data terminal ready) 893 

DTR (SCC) 1158 

_dumpflg ($4EE) 142 

Duochrom-Modus (TT-Video) 1048 

Duplicate file handle 233 
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EACCDN (-36) 203 
EBADRQ (~5) 38 
EBADSF (-16) 39 
ECS (68030) 1005 
EDITABLE (0x0008) 557,652 
EDRTVE (-46) 203 
EDRVNR (-2) 38 
EDVNRSP (-19) 39 
EFILNF (-33) 202 
EGENRL (-12) 39 
EgetPalette (XBIOS 85) 106 
EgetShift (XBIOS 81) 107 
EGSBF (-67) 204 
EIHNDL (-37) 203 
EIMBA (-40) 203 

Ein-/Ausgabeumlenkung 174, 209, 234 
Ein-Pegel bei MFP-Timer-Eingängen 875 
Einfachklick 756 
Eingänge (STE), analoge 1286 
BDMSERT (-18) 39 
EINTRN (-65) 204 
EINVFN(-32) 202 
Einzelblattpapier 154 
Einzelbyte-Transfer (ACSI) 986 
ELLIPSE (VDIll.GDP 5) 367 
ELLIPTICAL ARC (VDI11, GDP 6) 

369 

ELLIPTICAL PIE (VDI 11, GDP 7) 371 
EMEDIA (-7) 38 
EMLNF (-59) 203 
Empfangen von IKBD-Daten 935 
Empfänger (ACIA) 911 
Empfangspuffer (MFP-USART) 895 
Empfangsregister (ACIA) 911,914 
Empfangsregister (KBD) 927 
Empfangsregister (MFP-USART) 895 
Empfangsregister (MIDI-ACIA, 

Adr. $FF FC06) 915 
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Empfangsregister (Tastatur-ACIA, 

Adr. $FF FC02) 915 
Empfangsschieberegister (ACIA) 911 
Empfangsschieberegister (MFP-USART) 895 
Empfangsschieberegister (SCC) 1144 
Empfangstakt (ST-MFP-USART) 894 
Emulator-Unterstützung (68030) 1009 
Enable Clock (Megabus) 824 
Enable Cursor (VT52 ESC e) 9 
END DRAW AREA PRIMITIVE (81) 524 
END GROUP (11) 524 
Endoffile 209,212 
End-of-Interrupt-Modus (MFP) 888 
Endlospapier 154 
ENDMASK (BUTTER) 845 f. 

END_MCTRL (2) 691 
end_os ($4FA) 42,69 
ENDJUPDATE (0) 691 
ENHNDL (-35) 203 
ENMFIL (—49) 203 
ENSAME (-48) 203 
ENSMEM (-39) 203 
ENTER ALPHA MODE (VDI5, 

Escape 3) 484 

Enter reverse Video mode (VT52 ESC p) 9 

Envelope (PSG) 860 

Environment 66, 191, 539, 707 

EOTHER (-17) 39 

EP APER (-9) 38 

EPLFMT (-66) 204 

Epson 154 

EPTHNF (-34) 202 

ERANGE (-64) 204 

Erase beginning of display (VT52 ESC d) 8 
Erase beginning of line (VT52 ESC o) 9 
Erase entire line (VT52 ESC 1) 9 

ERASE TO END OF ALPHA SCREEN (VDI 5, Escape 9) 490 
ERASE TO END OF ALPHA TEXT LINE (VDI 5, Escape 10) 491 
Erase to end of page (VT52 ESC J) 8 
EREADF (-11) 39 
Ereignispuffer 538, 596 f. 
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Ereigniszähler (par. Schnittstelle) 910 
Ereigniszähler, MFP-Tiraer als 877 
ERLCKD (-58) 203 
ERROR (-1) 38 

Erweiterungskarte (Mega ST) 820 
ESCAPE (VDI5) 481 
ESCAPE 2000 (VDI 5, Escape 2000) 531 
ESECNF (-8) 38 
EsetBank (XBIOS 82) 107 f., 112 
EsetColor (XBIOS 83) 109 
EsetGray (XBIOS 86) 107, 110, 112 
EsetPalette (XBIOS 84) 111 
EsetShift (XBIOS 80) 112 
EsetSmear (XBIOS 87) 107, 112 f. 
etv_critic ($404) 59, 198, 704 
etv_term ($408) 59,200, 212, 266 
etvjimer ($400) 59, 197 
etv_xtra ($40C) 59 
Eulersche Zahl e (68882) 1027 
EUNCMD (-3) 38 
EUNDEV (-15) 39 
Event-Count-Mode (MFP-Timer) 877 
Event-CPX 717 

EVNTJBUTTON (AES 21) 608,615 
EVNT_DCLICK (AES 26) 618 
EVNT_DCLICKS (AES 26) 618 
evnt_evnt() 617 

EVNT_KEYBD (AES 20) 607,615 
EVNT_MESAG (AES 23) 612,615 
EVNT_MOUSE (AES 22) 610,615 
EVNT_MULTI (AES 25) 614 
EVNT TIMER (AES 24) 537,613 
EWRITF (-10) 38 
EWRPRO (-13) 39 
Exception 51,54,58,96,252,304 
Exception Enable byte (ENABLE) (68882) 1032 
Exception Status Byte (EXC) (68882) 1034 
Exception vectors 1010 

EXCHANGE BUTTON CHANGE VECTOR (VDI 125) 450 
EXCHANGE CURSOR CHANGE VECTOR (VDI 127) 453 
EXCHANGE MOUSE MOVEMENT VECTOR (VDI 126) 452 
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EXCHANGE TIMER INTERRUPT VECTOR (VDI118) 445 
exec_os ($4FE) 42, 69, 539,709 
EXIT (0x0004) 557,652 
EXIT ALPHA MODE (VDI 5, Escape 2) 483 
Exit reverse Video mode (VT52 ESC q) 9 
Exklusiv-Commands (MIDI) 918 
Extended Access (VME-Bus) 1188 
EXTENDEDINQUIRE FUNCTION 
(VDI 102) 334, 377, 384,456 
Extended Precision Format (68882) 1023 
Extended Real (68882) 1024, 1027 
Extended Sense (SCSI) 1092 
Extent-Descriptor-List (ACSI) 996 
Extemal Cycle Start (68030) 1005 
externe (Video-)Synchronisation beim ST 839 
Extra High Density 80 
E_CHNG (-14) 39,166 
E_CRC (-4) 38 
E_OK (0) 37,202 
E_SEEK (- 6 ) 38 
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F 


Farbpalette 151, 1352 
Farbregister 150, 835, 838,1056,1058 
FAST-MCU (TT) 1044 
FAST-RAM 182,194,1039,1042 
Fast-RAM-Puffer 79 
FAST-RAM-Erweiterungskarte 1043 
Fastload 194, 252 
FASTLOAD-EPROMS 966 
FAT (File-allocation-table) 14, 88,162 
Fattrib (GEMDOS 67) 166,227 
FA_ ARCHIVE (0x20) 165 
FA_ATTRIB (0x17) 246 
FAJHIDDEN (0x02) 165 
FA_READONLY (0x01) 165 
FA_SUBDIR (0x10) 165 
FA_SYSTEM (0x04) 165 
FA_VOLUME (0x08) 165 
FBAS-Signal 830 
FBcc(68881) 1343 
FCO, FC1, FC2 (Megabus) 823 
FC0..FC2 (68030) 1005 
Fclose (GEMDOS 62) 228 
Fcreate (GEMDOS 60) 165, 228 f, 
Fdatime (GEMDOS 87) 231 
FDBcc (68881) 1341 
_FDC 22, 80, 114, 140, 947, 949, 956 
FDC(TT) 1214 
FDC-Chip, Registerauswahl 816 
FDC-Command-Register 960, 978 
FDC-Data-Register 959, 978 
FDC-Feature 958 
FDC-Kommandos 960 
FDC-Kommandos, Typ I- 961 
FDC-Kommandos, Typ n- 966 
FDC-Kommandos, Typ III- 969 
FDC-Kommandos, Typ IV- 973 
FDC-Operation mit DMA 975 
FDC-Programmierung 974 
FDC-Register 958,974 
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FDC-Register-Durchgriff 817 
FDC-Schaltungsauszug 957 
FDC-Sector-Register 959 
FDC-Status-Register 9601,978 
FDC-Track-Register 958 
Fdelete (GEMDOS 65) 232 
Fdup (GEMDOS 69) 174,233 
Feedback 763 
Fehler, interner 204 
Fenster-Attribut 677 
Fensterattribute 578 
Fensterfarben 580 
Fensterverwaltung 772 
Fforce (GEMDOS 70) 174, 233 f. 

Fgetdta (GEMDOS 47) 235, 246 
fifo (Adr. $FF 8606) 818, 978,999 
FIFO-Buffer (ACSI) 992,999 
FIFO-Buffer (FDC) 976 

FIFO-Buffer (SCC), Condition-/Daten-/Frame-Status- 1144 
FIFO-Buffer (STE-Sound) 1306 
Fifo-Buffer löschen, DMA- 819 
FIFO, DMA- 814 
File handle 173,231 
File-Locking 201 
File-Selektor 574, 673,675, 753 
FILL RECTANGLE (VDI114) 358 
FILLED AREA (VDI9) 353,358 
Filled polygon (SA006) 313 
Filled rectangle ($A005) 312 
FILLED ROUNDED RECTANGLE 
(VDI 11, GDP9) 374 
Finescrolling (STE) 1315,1318 
Fire-Button (IKBD) 929 
Fire-Buttön-Informationen (STE) 1289 
FISJHATCH (3) 408 
FIS_HOLLOW (0) 408 
FIS_PATTERN (2) 408 
FIS_SOLID (1) 408 
FIS_USER (4) 408 
Fitt 746 

FLAG (SDLC/HDLC-Verfahren) 1139,1156 
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Fließkommaarithmetik (68882) 1019, 1023 
_FLK 81,201,230,236,238 

Floating Point Condition Code Byte (FPCC) (68882) 1033 

Floating Point Control Register (FPCR) (68882) 1032 

Floating Point Coprocessor-Karte (Megabus) 825 

Floating Point Instruction Address Register (FPIAR) (68882) 1035 

Floating Point Processor MC68881 1374 

Floating Point Register (68882) 1022 

Floating Point Status Register (FPSR) (68882) 1030, 1033 

Floating Point Unit (68882) 1019 

flock ($43E) 60, 79, 964, 975, 999 

Hock (GEMDOS 92) — Lock file 236 

Hopfmt (XBIOS 10) 22,114 

Floppy Disk Controller 947, 949,1354 

Floppy Disk Controller Select (FDC/ACSI-DMA) 816 

Hoppy Disk Interface (TT) 1214 

Fioppy-Disk-Lock (flock, Adr. $43E) 60, 79, 964, 975, 999 

Floprate (XBIOS 41) 60, 116 

Floprd (XBIOS 8) 17,118 

Hopver (XBIOS 19) 17,119 

Hopwr (XBIOS 9) 17,22,120 

FM0-/FM1 - Verfahren 1140,1162 

FMD_FINISH (3) 642 

FMD„GROW(l) 642 

FMD_SHRINK (2) 642 

FMD_START (0) 642 

FMOVE (68882) 1026 

FMOVEFPcr (68881) 1338 

FMOVE front FPn (68881) 1338 

FMOVECR (68881) 1337 

FMOVECR (68882) 1027 

FMOVEM (68882) 1027 

FMOVEMFPcr (68881) 1339 

FMOVEM FPn (68881) 1339 

FNOP (68881) 1343 

Folder 202, 220 f„ 227, 247 

FOLDR100.PRG 44,181 

Font 287, 316,402,472,477, 530 

FONTHDR 291 

Fopen (GEMDOS 61) 161, 228 f., 237 
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Force Extra Source Read (BLITTER, 

Adr. $FF 8A3D) 853 
Force file handle 234 
Force Interrupt (FDC) 960, 973 
FORM ADVANCE (VDI5, Escape 20) 501 
Form-CPX 717 
form height 289 
form width 289 
Format-Code (ACSI) 997 
Format drive (ACSI) 994 
Format-Parameter (SCSI-MODE SELECT) 1110 
FORMAT UNIT (SCSI) 1095 
Formatierung (Disk) 114, 949,970, 972 
Formatparameter (68882) 1027 
FORM_ALERT (AES 52) 643 
FORM_BUTTON (AES 56) 568,651 
FORM_CENTER (AES 54) 647 
FORMJDIAL (AES 51) 641,647 
FORM_DO (AES 50) 556, 640 
FORM_ERROR (AES 53) 645 
FORMJtEYBD (AES 55) 568,649 
FP-Datenregister (68881) 1333 
JFPU 78 
FPU (68882) 1019 
FPU-Befehlsnummer (68881) 1336 
FPU-Command-Register (68881, Adr. 

SFFFA4A) 1333 

FPU-Command-Word (68881) 1336 
FPU-Condition-Register (68881, Adr. 

$FF FA4E) 1333 
FPU-Control-Register (68881, Adr. 

SFFFA42) 1332 

FPU-Instruction Address-Register (68881, Adr. $FF FA58) 1333 
FPU-Konstanten-ROM (68881) 1337 
FPU-Operand-Register (68881, Adr. 

$FF FA50) 1333 
FPU-Register 538 

FPU-Register select-Register (68881, Adr. $FF FA54) 1333 
FPU-Response primitives (68881) 1344 
FPU-Response-Register (68881, Adr. 

$FF FA40) 1332 
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FPU-Restore-Register (68881, Adr. 

SFFFA46) 1333 
FPU-Save-Register (68881, Adr. 

$FF FA44) 1333 

Frame (SDLC/HDLC-Verfahren) 1138 
Frame (STE-DMA-Sound) 1296 
Frame-Address-Counter (STE, ab Adr. 

$FF 8908) 1297 

Frame-End-Adresse (STE, ab Adr. 

$FF 890E) 1297 

Frame-End-Signal (STE) 1299, 1305 
Frame-Start-Adresse (STE, ab Adr. 

$FF 8902) 1297 
Framing Error-Bit (ACIA) 914 
_FRB 79 

Jrclock ($466) 48,63 

Fread (GEMDOS 63) 240 

Frename (GEMDOS 86) 241 

Frequenzeinstellung (PSG) 862 

FRESTORE (68882) 1031 

FSAVE (68882) 1031 

FScc (68881) 1340 

Fseek (GEMDOS 66) 242 

FSEL_EXINPUT (AES 91) 574,673, 675, 753 

FSELJNPUT (AES 90) 574, 673,675, 753 

Fsetdta (GEMDOS 26) 244,246 

Fsfirst (GEMDOS 78) 235, 244 f., 248 

FSINCOS (68881) 1337 

FSINCOS (68882) 1028 

FSMGDOS 288 

Fsnext (GEMDOS 79) 235, 244, 248 

FTRAPcc (68881) 1342 

FTRAPcc (68882) 1031 

FULL (0x0004) 678,693 

Füllattribut 353, 360, 363, 365, 367, 371, 374, 465 

Füllfarbe 411 

Füllmuster 413 

Funktionscode (68030) 1005 

Funktionscode (Megabus) 823 

FUNNEL (TT) 1039, 1053 

future catastrophes 39 
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Jfverify ($444) 17,61 

Fwrite (GEMDOS 64) 249 

FXSR (BUTTER, Adr. $FF 8A3D) 853 
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G 


Ganzzahl-Format (68882) 1023 
GAP (Disk) 971 
GDOS.PRG 286,295, 316, 330 
GDP 332,359 
GEM Draw 523 
GEM-Versionen 533 
GEMDOS-Bindings 202 
GEMDOS-Dateisystem 161 
GEMDOS-Erweiterungen 200 
GEMDOS-Fehler 645 
GEMDOS-Pool 180,251 
GEMDOS-Puffer 170 
GEMDOS-Vektoren 197 
GEMDOS-Versionsnummer 269 
GEMFILE.GEM 528 
Gemini 10,547 
GEM_MUPB 42 

General-Purpose-I/O-Port (GPIP) (ST) 869,871 

GENERALIZED DRAW1NG PRIMITIVE (GDP) (VDI11) 359 

GENERATE SPECIFIED TONE (VDI 5, Escape 61) 511 

GENLOCK-Anwendungen (STE) 1285, 1313 

Gerätetreiber 287, 330 

Get current directory 224 

Get date 270 

Get default drive 223 

Get drive free space 222 

GetDTA 235 

Get pixel ($A002) 311 

GET PIXEL (VDI 105) 423 

Get time 271 

Get version number 269 

Get/Set file attributes 227 

Get/Set file timestamp 231 

Get/Set/lnquire Supervisor mode 268 

Getbpb (BIOS 7) 14, 88,162, 166, 171 

getcookie 743 

GetFirstRect 740 

Getmpb (BIOS 0) 60,65,89 

GetNextRect 740 
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Getrez (XBIOS 4) 107, L12,121, 152 
Gettime (XBIOS 23) 122 
Get_Biiffer 743 
Gl-Chip 80, 105,123,138 
Giaccess (XBIOS 28) 123 
giread (PSG, Adr. $FF 8800) 861 
giselect (PSG, Adr $FF 8800) 861 
giwrite (PSG, Adr.$FF 8802) 861 
GKS 275 

GLOBAL-Feld 542, 594 f. 

GLUE-Chip, ST- 790, 804 f„ 808, 822, 824 
gpip (MFP, Adr. $FF FA01) 869 
GPIP-Data-Register (ST-MFP, Adr. 

$FF FA01) 869,978, 987, 999 

GPIP-Data-Register (TT-MFP, Adr. $FF(FF) FA81) 1063,1116 
GPU-Done-Signal 55, 870 
Grafik-Auflösung 62,121, 152, 279, 1047 
Grafik-Cursor 427,429,443, 446 ff., 

452 f., 499 f. 

Grafikbetriebsart (ST(E)) 836 
Grafikgrundfunktionen 332, 359 
Grafiksystem, ST- 787, 827 
Grafiktablett 331,497 
GRAF_DRAGBOX (AES 71) 655 
GRAF_GROWBOX (AES 73) 658 
GRAF_HANDLE (AES 77) 337, 540, 666 
GRAF_MBOX (AES 72) 657 
GRAF_MKSTATE (AES 79) 669 
GRAF_MOUSE (AES 78) 667 
GRAF_MOVEBOX (AES 72) 657 
GRAF_RUBBERBOX (AES 70) 654 
GRAF_RUBBOX (AES 70) 653 
GRAF_SHRlNKBOX (AES 74) 660 
GRAF_SLIDEBOX (AES 76) 664, 691 
GRAF_WATCHBOX (AES 75) 662 
Graustufen 110 
GRECT 577 
GREEN (3) 558 

Gruppe 0-Kommandos (SCSI) 1089 
Gruppencode (SCSI) 1087 
GSTMCU, STE 788 
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GSX 275 
G_BOX (20) 554 
G_BOXCHAR (27) 555 
G_BOXTEXT (22) 554 
G_BUTTON (26) 554 
G_FBOXTEXT 636 
G_FBOXTEXT (30) 555 
G_FTEXT (29) 555,636 
G_IBOX (25) 554 
GJCON(31) 555 
GJMAGE (23) 554 
G_PROGDEF 554 
G_STRING (28) 555 
G_TEXT (21) 554 
G_TITLE (32) 555 
G_USERDEF 778 
G_USERDEF (24) 554 
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H 


H-Ablenkfrequenz, ST(E)-Monochrom- 828 
H-Signal bei Colorbetrieb (ST(E)) 829 
H-Synchronimpulse (ST(E)) 838 
Häkchen 558, 620 

Halftone-Operation-Register (BLUTER, Adr. $FF 8A3A) 849 f. 
Halftone-RAM (BLUTER, ab Adr. 

$FF 8A00) 849 
HALT (68030) 1008 
HALT (Megabus) 823 
Handle 173,231 
Handshake (ACSI) 985 
Handshake (MIDI) 922 
Handshake (SCSI), REQ/ACK- 1081 
Handshake (serielle Schnittstelle) 870, 892, 904 
Handshaking (par. Schnittstelle) 907 
HARD COPY (VDI5, Escape 17) 498 
Hard Disk Controller Select (FDC/ACSI-DMA) 816 
Hardcopy 67,69,142,498 
Harddisk-Controller (ACSI-Befehlssatz) 991 
Hardware-Register (Kurzübersicht) 1349 
Hardware-Uhr 122, 153 
Hardwareerweiterungen (TT), künftige 1063 
Hardwareunabhängigkeit 782 
Harvard-Architektur 1003 
HBLANK-Interrupt 841, 882 
HD-Betrieb 22, 80, 950 f., 958, 1214 

HD-Betrieb-Taktumschaltung (TT/MEGA STE, Adr. $FF(FF) 860E) 1216 

HD-Diskette 950,1214 

HDLC-Verfahren 1138,1158 

hdv_boot ($47A) 16, 20, 64 

hdvbpb ($472) 16,64,88 

hdv_init ($46A) 16, 60, 63, 94 

hdv_mediach ($47E) 16, 64 

hdv_rw ($476) 16, 64, 94 

Head load (FDC) 951 

HIDE CURSOR (VDI 123) 447 

Hide mouse ($A00A) 308, 318 

HIDETREE (0x0080) 557 

High-Density 22, 80, 950 f., 958, 1214 
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High-Level Data Link Control 1138 

High resolution (ST(E)) 833 

High-water mark (ser. Schnittstelle) 904 

Hilfs- und Versorgungsleitungen (VME-Bus) 1192 

Hintergrund-Fenster 580 

HOG-Bit (BLUTER, Adr. $FF 8A3C) 854 

Hohe Auflösung (ST(E)) 833 

HOME ALPHA CURSOR (VDI5, 

Escape 8) 489 

Home Cursor (VT52 ESC H) 8 
HOP-Register (BLUTER, Adr. 

$FF 8A3A) 849 

Horizontal-Blanking-Interrupt 53, 841, 882 
Horizontal Iine ($A004) 312 
Horizontal offset table 290, 471 
Horizontalfrequenz, ST(E)-Monochrom 827 
Hostadapter, MEGA STE- 1216 
Hot spot 307, 318 f., 443 
HOTCLOSEBOX (0x1000) 678 
HOURGLASS (2) 667 
HP-Laserdrucker 321 

HScroll-Register (STE, Adr. $FF 8265) 1286, 1318 

HSLIDE (0x0800) 678,693 

Hüllkurve (PSG) 860, 864 

HuSHI 171 

_hz_200 ($4BA) 66 
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I 

I/O (SCSI) 1077 

I/O-Ports (PSG) 861,864 

I/O-Redirection 174, 209, 234 

IACK (VME-Bus) 1191,1193 

IACKIN (VME-Bus) 1191,1193 

IACKOUT (VME-Bus) 1191,1193 

ICONBLK 562 

ID-Address-Mark (Disk) 970 

ID-Feld (Disk) 958,962, 967,977 

ID-Nummer (Bootsektor) 92, 140 

Identifikation, Disklaufwerks- 953 

IEEE Standard for Binary Floating-Point Arithmetic 1023 

IERA (ST-MFP, Adr. $FF FA07) 886 

DERAJIT (TT-MFP, Adr. $FF(FF) FA87) 1068 

IERB (ST-MFP, Adr. $FF FA09) 886 

IERB_TT (TT-MFP, Adr. $FF(FF) FA89) 1069 

IKBD-Chip 56, 84, 86, 124, 129, 922 

IKBD-Kommandos 935 

IKBD-Treiberstatus 129 

Ikbdws (XBIOS 25) 124 

IMG-Datei 504 

Immediate Interrupt (FDC) 974 

IMRA (ST-MFP, Adr. $FF FA13) 887 

IMRAJIT (TT-MFP, Adr. $FF(FF) FA93) 1069 

IMRB (ST-MFP, Adr. $FF FA15) 887 

IMRB_TT (TT-MFP, Adr. $FF(FF) FA95) 1069 

In-/Output (SCSI) 1077 

Index (FDC) 952 

Indeximpuls 946,964, 974 

INDIRECT (0x0100) 557 

Indirekte Farbgebung 835 

JNF 81 

INFO (0x0010) 678,693 

Inform GEMDOS of “alternative” memory 250 

IN1T SYSTEM FONT (VDI5, 

Escape 102) 530 
Initialization ($A00O) 305 
Initiator (ACSI) 981 
Initiator (SCSI) 1073 
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Initmous (XBIOS 0) 125 
INPUT CHOICE, REQUEST MODE 
(VDI30) 435 

INPUT CHOICE, SAMPLE MODE 
(VDI30) 437 

INPUT LOCATOR, REQUEST MODE (VDI28) 427 
INPUT LOCATOR, SAMPLE MODE (VDI 28) 429 
INPUT STRING, REQUEST MODE 
(VDI 31) 439 

INPUT STRING, SAMPLE MODE 
(VDI 31) 441 

INPUT VALUATOR, REQUEST MODE (VDI 29) 431 
INPUT VALUATOR, SAMPLE MODE (VDI 29) 433 

INQUIRE ADDRESSABLE ALPHA CHARACTER CELLS (VDI 5, 

Escape 1) 482 

INQUIRE CAMERA FILM NAME 
(VDI 5, Escape 92) 519 
INQUIRE CELL ARRAY (VDI 27) 474 
INQUIRE CHARACTER CELL WIDTH (VDI 117) 470 
INQUIRE COLOR REPRESENTATION (VDI 26) 459 
INQUIRE CURRENT ALPHA CURSOR ADDRESS (VDI 5, Escape 15) 496 
INQUIRE CURRENT FACE INFORMATION (VDI 131) 477 
INQUIRE CURRENT HLL AREA ATTRIBUTES (VDI 37) 465 
INQUIRE CURRENT GRAPHIC TEXT ATTRIBUTES (VDI 38) 466 
INQUIRE CURRENT POLYLINE ATTRIBUTES (VDI 35) 461 
INQUIRE CURRENT POLYMARKER ATTRIBUTES (VDI 36) 463 
INQUIRE FACE NAME AND INDEX (VDI 130) 402,472 
INQUIRE INPUT MODE (VDI 115) 476 
INQUIRE JUSTTFIED GRAPHICS TEXT (VDI 132) 480 
INQUIRE PRINTER SCAN (VDI 5, Escape 24) 506 
INQUIRE TABLET STATUS (VDI 5, Escape 16) 497 
INQUIRE TEXT EXTENT (VDI 116) 468 
INQUIRY (SCSI) 1103 
Insert line (VT52 ESC L) 8 
INT(ACSI) 984 
INT 3 und 5 (Megabus) 825 
Integer Data Format (68882) 1023 
Interleave (ACSI) 994 
Interleave (SCSI) 1096 
Interleaved Bitplanes 281 
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Internal Microsequencer Status (68030) 1009 
Interrogate mouse position (IKBD $D) 937 
Interrogate time-of-day clock (IKBD $IC) 940 
Interrupt (68030) 1007 

Interrupt (ACIA), Sender-/Empfänger- 911,913 
Interrupt (FDC) 961 
Interrupt (FDC), VBlank- 964 
Interrupt (MFP-USART), RCV-Buffer-full- 865, 900 
Interrupt (MFP-USART), RCV-Error- 895, 899 f. 

Interrupt (MFP-USART), XMIT-Buffer-empty- 895, 903 
Interrupt (MFP-USART), XMIT-Error- 895, 902 
Interrupt (SCC), DCD- 1170 f. 

Interrupt (SCC), DSR- 1171 

Interrupt (SCC), Special Receive Condition- 1144 

Interrupt (SCU), Software- 1197 

Interrupt (TT-SCSI) 1116 

Interrupt (TT-Uhr) 1202 

Interrupt (VME-Bus) 1190 

Interrupt an MFP, FDC/ACSI- 870 

Interrupt-Anforderung (VME-Bus) 1190 

Interrupt-Ausgang (TT-SCSI) 1116 

Interrupt-Bearbeitung CPU<->MFP 884, 889 

Interrupt-Bus (VME-Bus) 1185, 1190 

Interrupt-Ebenen (ST) 882 

Interrupt-Eingang, ST-MFP- 869 

Interrupt-Enable-Reg. A (ST-MFP, Adr. $FF FA07) 886 

Interrupt-Enable-Reg. A (TT-MFP, Adr. $FF(FF) FA87) 1068 

Interrupt-Enable-Reg. B (ST-MFP, Adr. $FF FA09) 886 

Interrupt-Enable-Reg. B (TT-MFP, Adr. $FF(FF) FA89) 1069 

Interrupt-Erkennung (VME-Bus) 1191 

Interrupt-in-Service-Register (MFP) 889 

Interrapt-in-Service Register A (ST-MFP, Adr. $FF FA0F) 888 

Interrupt-in-Service-Register A (TT-MFP, Adr. $FF(FF) FA8F) 1069 

Interrupt-in-Service Register B (ST-MFP, Adr. $FF FA11) 888 

Interrupt-in-Service-Register B (TT-MFP, Adr. $FF(FF) FA91) 1069 

Interrupt-Kanäle (MFP-USART) 895 

Interrupt-Leitung zum MFP (BLITTER) 855 

Interrupt-Level 881 

Interrupt-Mask-Register (SCU) 1195 

Interrupt-Mask-Register A (ST-MFP, Adr. $FF FAB) 887 

Interrupt-Mask-Register A (TT-MFP, Adr. $FF(FF) FA93) 1069 
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Interrupt-Mask-Register B (ST-MFP, Adr. $FF FA15) 887 

Interrupt-Mask-Register B (TT-MFP, Adr. $FF(FF) FA95) 1069 

Interrupt Pending (68030) 1007 

Interrupt-Pending-Register (MFP) 889 

Interrupt Pending Register (SCC) 1174 

Interrupt-Pending-Register A (ST-MFP, Adr. FF FAOB) 886 

Interrupt-Pending-Register A (TT-MFP, Adr, $FF(FF) FA8B) 1069 

Interrupt-Pending-Register B (ST-MFP, Adr. FF FAOD) 886 

Interrupt-Pending-Register B (TT-MFP, Adr. $FF(FF) FA8D) 1069 

Interrupt-Prioritäten 881 

Interrupt-Prioritäten (SCC) 1150 

Interrupt Priority Level (68030) 1007 

Interrupt-Priority-Level-Anschlüsse (CPU) 881 

Interrupt Request-Bit (ACIA) 915 

Interrupt-Request-Leitungen (VME-Bus) 1190 

Interrupt Request vom SCC-DMA 1063 

Interrupt Request vom SCSI-Controller (TT) 1064 

Interrupt Request von TT-Uhrenchip 1064 

Interrupt-Service-Routine (VME-Bus) 1192 

Interrupt Stack Pointer (ISP) (68030) 1010 

Interrupt-Steuerregister (MFP) 886, 1068 

Interrupt Vektor (SCC) 1174 

Interrupt-Vektor-Adresse 883 

Interrupt Vektor-Register (SCC) 1153 

Interrupt-Vektor-Register (ST-MFP, Adr. $FF FA17) 888 

Intenupt-Vektor-Register (TT-MFP, Adr. $FF(FF) FA97) 1069 

Interrupt-Vektoren, Lage der ST-MFP 885 

Interrupt-Vektomummer 882, 889 

Interrupt, ACSI- 987, 989 

Interrupt, Autovektor 882 

Interrupt, FDC- 960, 978 

Interrupt, HBLANK- 882 

Interrupt, VBLANK- 882 

Interruptbehandlung (TT- und ST-MFPs (TT)) 1066 
Interruptbehandlung, MC68000- 881 
Interruptkanal (MFP) 886 
Interruptkanal, MFP-Timer- 873 
Interruptroutine, Tips für HBlank- 882 
Interrupts (68030), Steuersignale für 
1007 

Interrupts (SCC), Empfänger- 1149 
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Interrupts (SCU), Verwaltung der 1195 
Interrupts durch Megabus 825 
Interrupts durch MFP 883 
Interrupts durch TT-MFP 1066 
Interrupts softwaregesteuert ausgelöst (SCU) 1195 
Interrupts vom Systemboard (SCU) 1195 
Interrupts vom VME-Bus (SCU) 1196 
Interrupts, Prioritäten der MFP- 883 
Interruptsteuerung, Video-Controller- 840 
Interruptvektoren, Lage der TT-MFP- 1068 
INTJN 310 

INTR-Anschluß (FDC) 960 f„ 974 

IOA6 (TT-PSG) 1212 

IOA7 (TT-PSG) 1212 

Iorec (XBIOS 14) 98,127 

IOREC-Struktur 127 

IPEND (68030) 1007 

IPL0..IPL2 (68000) 881 

IPL0..IPL2 (68030) 1007 

IPRA (ST-MFP, Adr. $FF FA0B) 886 

IPRAJTT (TT-MFP, Adr. SFF(FF) FA8B) 1069 

IPRB (ST-MFP, Adr. $FF FA0D) 886 

IPRB_TT (TT-MFP, Adr. $FF(FF) FA8D) 1069 

IRQ-Anschluß (ACIA) 915, 919 

IRQ 1. .7 (VME-Bus) 1190, 1193 

isatty() 178,242 

ISRA (ST-MFP, Adr. $FF FA0F) 888 
ISRA_TT (TT-MFP, Adr. $FF(FF) FA8F) 1069 
ISRB (ST-MFP, Adr. SFF FA11) 888 
ISRB_TT (TT-MFP, Adr. $FF(FF) FA91) 1069 
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J 

Jdisint (XBIOS 26) 128 
Jenabint (XBIOS 27) 128 
JOYBSTAT (STE, Adr. $FF 9200) 1289 
JOYDIR (STE, Adr. $FF 9202) 1289 f. 

Joystick 129, 497, 929,938 
Joystick-Button-Status (STE, Adr. 

$FF 9200) 1289 

Joystick-Direction (STE, Adr. $FF 9202) 1289 
Joystick interrogation (IKBD $16) 939 
Joystick-Modus 943 

Joystick-Richtungsinformation (STE) einiesen 1288 

Joystickabfrage 939, 943 

Joystickports beim STE 1287, 1289 ff., 1293,1368 

JUST GO 258 

JUST GO, THEN FREE 260 

JUSTIFIED GRAPHICS TEXT (VDI11, GDP 10) 375 
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K 

k-Faktor (68881) 1338 
k-Faktor (68882) 1027 
Kamera-Treiber 327, 331 
Kanal (MIDI) 917 
Kanäle 173 

Kbdvbase (XBIOS 34) 129 
KBDVECS 129 
Kbrate (XBIOS 35) 131 
Kbshift (BIOS 11) 44, 65, 83, 91, 209 
kcl_hook ($5B0) 11,72 
Keksdose 72,743 

keybd (Tastatur-ACIA, Adr. $FF FC02) 915 
Keyclick 64, 859 

keyctl (Tastatur-AdA, Adr. $FF FC00) 915 
KEYTAB 132 
Keytbl (XBIOS 16) 100, 132 
Klammeraffe 559 
Klangerzeugung, digitale 916 
Kommandos an IKBD 935 
Kommandozeile 244 
Kommunikationskanäle (SCC) 1141 
Kommunikationsprotokoll (68881) 1331 
Kommunikationsprotokoll (68882) 1026 
Konsole 64, 83 ff., 161, 237 
Konstanten-ROM (68882) 1027 
Kontrollelemente 578 
Kontrollregister (TT-Uhr) 1203 
Konvention 748 
Koordinatensystem 277, 288 
Koordinatensystem, normalisiertes 277 
Kopfberuhigungszeit (FDC) 962 
Kopfschlitten (Disk) 946 
Kreiszahl (68882) 1027 
Kurzzeitgedächtnis 748 
K_ALT (0x0008) 455, 602,609, 611, 669 
K_CTRL (0x0004) 455, 602, 609, 611, 669 
K_LSHIFT (0x0002) 455, 602,609, 611, 669 
K_RSHIFT (0x0001) 455, 602, 609,611,669 
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L 

LAN-Anschluß umschalten (TT-PSG) 1212 
Länderkennung 43 

Längsparitätsverfahren (Datenübertragung) 1137 
LASTOB (0x0020) 557 
Laufwerk 66, 953 

Laufwerk, aktuelles 160, 222 f., 225 f. 

Laufwerk, extemes/intemes 955 
Laufwerk, logisches 87, 95, 226 
Laufwerke, vorhandene 225 
Laufwerksmotor (Disk) 964 
Laufwerksparameter (ACSI) 997 
Lautsprecher im TT Ein-/Ausschalten 1212 
Lautstärke, Kontrolle der PSG- 859 
LBA (SCSI) 1088 
LBLACK (9) 559 
LBLUE (12) 559 
LCYAN (13) 559 
LDS (Lower Data Strobe) 793, 807 
LDS (Megabus) 823 
Lese-Elektronik (Disk) 945 
Level-Control-Bits (PSG) 864 
LFARROW (0x0200) 678,693 
LGREEN (11) 559 
Library-Format 197 
Light-Gun/-Pen (STE) 1286,1289 
Lightpen, X-Position (STE, Adr. 

$FF 9220) 1290 
Lightpen, Y-Position (STE, Adr. 

$FF 9222) 1290 
Line-A 301 

Line-A-Vektor ($28) 52 
Line-F-Trap (68881) 1331 
Line-F-Trap (68882) 1026 
Line-F-Vektor ($2C) 53 

Line-Number-Register (BLITTER, Adr. $FF 8A3C) 850 
Line-width-Register (STE, Adr. $FF 820F) 1319 
LINEA 307 

linewid (STE, Adr. $FF 820F) 1319 
Linie 347,369, 384, 386 ff., 461 
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Linked Commands (SCSI) 1089 
Lisa 159 

LMAGENTA (15) 559 
LMC1992 (STE) 1308,1311 
LOAD AND GO 256 
LOAD FONTS (VDI119) 343 
Load mouse position (IKBD $E) 937 
LOAD, DON’T GO 257 
Load/Execute Process 256 
Logbase (XBIOS 3) 62, 133, 152 
Logical Unit (SCSI) 1073,1087 
Jongframe ($59E) 71 
Lost data-Bit (FDC) 968 f. 

Loveman, Jason 159 
Low resolution (ST(E)) 834 
Low-water mark (ser. Schnittstelle) 904 
Lower-Data-Strobe 793 
Lower-Data-Strobe (Megabus) 823 
LRED(10) 559 
LUN (SCSI) 1087 
LWHITE (8) 559 
LYELLOW (14) 559 
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M 

MACCEL3 595 

Macintosh 572, 580 

Maddalt (GEMDOS 20) 183, 250 

MAGENTA (7) 558 

magisches Langwort, (Cartridge) 809 

Magnetfelder, fremde 946 

Magnetschicht 945 

Make-Code (IKBD) 931 

Malloc (GEMDOS 72) 179,181, 251, 254,266, 594, 695 
Manchester-Codierung (SCC) 1140 
MAPTAB 12 

Marker 349, 391, 393, 395, 463 
Markierungsbyte (Disk) 973 
Maschinentyp 79 

Maskierung eines Interrupt-Kanals (MFP) 887 

Master (VME-Bus) 1187, 1189 

Master Stack Pointer (MSP) (68030) 1010 

Mastergerät (MIDI) 916 

Mastertakt (STE) 1313 

Matrixdrucker 154 

Maus 125,446,448,450,452,497,929, 931 f. 

Maus-Ereignis 543 

Maus-Skalierung 937, 942 

Mausabfrage 129, 938 

Mausbewegung 931,933,935,937,942 

Mausbewegungsmodus, absoluter/relativer 936, 942 

Mauselektronik 933 

Mausknopf-Ereignis 543 

Mausposition 669 

Maustaste (IKBD) 929,936 

Mauszeiger 632, 756, 764 

MC146818A 1201 

MC68000 793 f. 

MC68030 1003 
_MCH 79 
MCU (TT) 1042 
MD 89 

_md($49E) 65 

MD_ERASE (4) 378 
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MD_REPLACE (1) 378 
MD_TRANS (2) 378 
MD_XOR (3) 378 

Media change 21, 64, 92, 166, 953, 1114 
Mediabytes 165 

Mediach (BIOS 9) 15, 64, 92,162 
Medienwechsel 21, 64, 92, 166, 953,1114 
Medium Resolution (ST(E)) 834 
MEGAST-ROMs 802 
MEGAST-Serie 787 
Megabit-RAMs 798 
Megabit-ROM-Chips, ST- 802,804 
Megabit-ROM-Chips, TT- 1037 
Megabus 821 

Megabus-Anschlußbelegung 821 
Megabus-Stromversorgung 825 
Megabus, Interrupts durch 881 
Megabus, Signaltiming am 821 
_membot ($432) 60 
memcntrl ($424) 59, 801 
memconf (Adr. $FF 8001) 801 
Memory-Configuration-Register (Adr. 

SFF8001) 801 

Memory Control Unit (TT) 1042 
Memory Form Definition Block 284 
Memory load (IKBD $20) 941 

Memory Management Status Register (MMUSR) (68030) 1017 

Memory Management Unit (68030) 1014 

Memory-Management-Unit (MMU) 790, 797 

Memory read (IKBD $21) 941 

jmemtop ($436) 60 

memval2 ($43A) 59 f., 70 

memval3 ($51A) 59, 70 

memvalid ($420) 59 f., 70 

Menü 749,764 

Menühintergrund 540 

Menüleiste 619 

Menütitel 622 

MENU BAR (AES 30) 549, 619,624 f. 

MENU_CLICK (AES 37) 548, 627 
MENUJCHECK (AES 31) 620 
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MENU JENABLE (AES 32) 621 
MENU_REGISTER (AES 35) 625 
MENU TEXT (AES 34) 585,623 
MENUJTNORMAL (AES 33) 622 
MENUJJNREGISTER (AES 36) 626 
Message (SCSI) 1076 
Message Codes (SCSI) 1085 
message event 543 
MESSAGE-Phase (SCSI) 1080, 1084 
Message-Queue 538, 596 f. 

Meta-DOS 14,24, 36, 160,162, 183, 191, 201, 575 

Metafile-Treiber 323, 331, 340, 521, 523, 528 

METAHDR 324 

Metainit (XBIOS 48) 134 

MEVENT 617 

MFDB 284 f., 417 

MFORM 318,668 

MFP(ACSI) 987 

MFP(FDC) 958,960 

MFP (MIDI/Tastatur) 919,929 

MFP (par. Schnittstelle) 909 

MFP (ser. Schnittstelle) 893 

MFP 68901-Timer 157 

MFP-Einbindung beim TT 1062 

MFP-I/O-Port-Datenrichtung 872 

MFP-USART-Register 895 

MFP, Interrupts 128, 135 

MFP, Monochrom-Detect-Signal zum 829 

MFP, ST- 869 

MFP, Takt für 872 

MFP, TT- 1063 

Mfpint (XBIOS 13) 50, 135 

Mfree (GEMDOS 73) 253 

MFsave 744 

Microwire-Interface 1286, 1308 f. 

MIDI 56, 83 ff., 129, 136, 916 
midi (MIDI-ACIA, Adr. $FF FC06) 915,1380 
MDDI-ACIA, Interrupt von 870 
MIDI-Bus 919 

MIDI-Empfangsregister (MIDI-ACIA, Adr. $FF FC06) 915,1380 
MIDI-in/out 919 
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MIDI-Schnittstelle, technische Realisierung der 919 
MIDI-Senderegister (MIDI-ACIA, Adr. $FF FC04) 915 
MIDI-Statusregister (MIDI-ACIA, Adr. $FF FC04) 915 
MBDI-Steuerregister (MIDI-ACIA, Adr. $FF FC04) 915 
MIDI-Thru 919 

midictl (MIDI-ACIA, Adr. $FF FC06) 915 
Midiws (XBIOS 12) 136 
Mikrocontroller (Keyboard) 922 
Miller 748 
Minix 20,24 
MiNT 252 

Mitteilungs-Ereignis 543 

Mittlere Auflösung (ST(E)) 833 

MMU (68030) 1014 

MMUDisable (68030) 1009 

MMU, ST- 790,796 

MMUDIS (68030) 1009 

MMUs, IMP- 799 

MN_SELECTED (10) 544 

Mode-Control-Block (IKBD) 923 

Mode Control Byte (MODE) (68882) 1032 

Mode select 996 

Mode sense 998,1111 

MODEM 1 (TT-MFP) 1061 

MODEM 2 (TT-MFP) 1063 

Modulator (ST(E)) 832 

Modus Commands (MIDI) 919 

Monitorbuchse 827, 1047, 1314 

MONO-Modus (MIDI) 917 

Mono-Modus (STE) 1296 

Monochrom-Betrieb (STE) 827 f. 

Monochrom-Betriebsart 837,1047 

Monochrom-Detect-Signal 57, 829, 870, 1061 

Monochrom-Monitor für die Colorbetriebsart (ST(E)) 832 

Motor on (FDC) 951, 962 

MOVE (0x0008) 678,693 

MPB 89 

MRETS 724 

MS-DOS 140,159,645,748 
MSG (SCSI) 1076 
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Mshrink (GEMDOS 74) 195,251,254 
Multifunktionsbaustein MFP 68901 869, 1061,1369 
Multitasking 536 
Mupfel 10 

Musical-Instruments-Digital-Interface (MIDI) 916 

Muskelgedächtnis 746 

MUJBUTTON(0x0002) 616 

MUKEYBD (0x0001) 616 

MU_M1 (0x0004) 616 

MU_M2 (0x0008) 616 

MU_MES AG (0x0010) 616 

MUTIMER (0x0020) 616 

MWDATA (STE, Adr. $FF 8922) 1309 

MWMASK (STE, Adr. $FF 8924) 1309 

Mxalloc (GEMDOS 68) 183,255,266 

M_OFF (256) 668 

M_ON (257) 668 
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N 

NAME (0x0001) 678,693 
NAMENLOS 751 
NAN (68882) 1024,1031 
NDC-Koordinatensystem 277, 332 
_NET 81,200 f. 

Netzwerk-Standard 81,2001 
Netzwerkanschluß (SCC) 1141 
NEWDESK.INF 539,705 
_nflops ($4A6) 16,63,65 
NFSR (BLITTER, Adr. $FF 8A3D) 853 
Nibble-Mode-Zugriffe (TT) 1044 
Niedrige Auflösung (ST(E)) 834 
NIL 552 

No Final Source Read (BLITTER, Adr. $FF 8A3D) 853 

Non-Autovektor-Interrupt 884, 888 

Non Maskable Interrupt (Megabus) 825 

Non Volatile Memory 137 

NONE 556 

NONEXTENDED SENSE (SCSI) 1091 
NORMAL (0x0000) 557,663 
NOT-READY-LIST 536 
NOTE (1) 644 
NOJCON(O) 644 
NRZ(I)-Verfahren 1140,1162 
NTSC-Modus 61 
nvbls ($454) 49,62 
NVM 137 

NVMaccess (XBIOS 46) 137 
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o 

OBJC_ADD (AES 40) 628 

OBJCCHANGE (AES 47) 638 

OBJC_DELETE (AES 41) 629 

OBJC_DRAW (AES 42) 565, 630, 647 

OBJC_EDIT (AES 46) 636,649 

OBJCJFIND (AES 43) 557,632 

OBJCLOFFSET (AES 44) 551, 634 

OBJCORDER (AES 45) 635 

OBJECT 553 

Objekt-Datei 196 

Objekt-Flags 556 

Objektfarben 558 

Objektstatus 557 

Objekttypen 554 

ob_spec 555 

ob_state 638 

ob_type 554 

OCS (68030) 1005 

Offgibit (XBIOS 29) 138 

OHEADER 196 

OMNI-Modus (MIDI) 916 

On-Chip-Cache 1003 

Ongibit (XBIOS 30) 138 

_OOL 81 

OP (BUTTER, Adr. $FF 8A3B) 845 
OP-Code (SCSI) 1087 
Open file 237 

OPEN VIRTUAL SCREEN WORKSTATION (VDI100) 337, 339 
OPEN WORKSTATION (VDI 1) 330,337 f„ 456 
Operand Cycle Start (68030) 1005 
Operation-Register (BLITTER, Adr. 

$FF 8A5B) 845 
Operationscode (ACSI) 990 
Operationsende (FDC) 958, 960 
Optokoppler (MIDI) 919 
Ordner 202, 220 f., 227, 247 
Oren, Tim 159 
OSHEADER 40,144 
os_magic 144 
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OUTLINED (0x0010) 558,663 
OUTPUT ALPHA TEXT (VDI5, 

Escape 25) 508 

OUTPUT BIT IMAGE FILE (VDI 5, Escape 23) 504 
OUTPUT CURSOR ADDRESSABLE ALPHA TEXT (VDI 5, Escape 12) 
493 

OUTPUT WINDOW (VDI 5, Escape 21) 502 
Overrun Error (MFP-USART) 900 
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Packed Decimal Real Data Format (68882) 1025 
PADDLO (STE, Adr. $FF 9210) 1292 
PADDL1 (STE, Adr. $FF 9212) 1292 
PADDL2 (STE, Adr. $FF 9214) 1.292 
PADDL3 (STE, Adr. $FF 9216) 1292 
Paddle O-Position (STE, Adr. $FF 9210) 1292 
Paddle 1-Position (STE, Adr. $FF 9212) 1292 
Paddle 2-Position (STE, Adr. $FF 9214) 1292 
Paddle 3-Position (STE, Adr. $FF 9216) 1292 
Paddle-Zähler-Register (STE) 1292 
Page-Descriptor (68030) 1015 

Paged Memory Management Unit (PMMU) (68030) 1003, 1015 

PAL-Modus 61 

Paletteregister 1056, 1314 

palmode ($448) 61 

Papierformate 288 

Parallelport als Eingang (PSG) 909 

Parallelport-Register, MFP- 869 

Parameter für Fehlerbehebung (SCSI-MODE SELECT) 1108 

Parameterblock (ACSI-MODE SELECT) 996 

Parität (MFP-USART) 896 

Parität (SCSI) 1077 

Paritätsbit 896 

Parity Error-Bit (ACIA) 915 

Parity-Fehler (MFP-USART) 900 

Parity, Even-/Odd- 896 

PARMBLK 564 

Partitionseintrag 26 f. 

Partitionstypen 27 

Patch-Programme (ser. Schnittstelle) 905 
PATH 61 

Pause output (IKBD $13) 938 
PBDEF 142 

PC-GEM 642,646, 659, 661,667 
PCM-Soundkanäle 1286 

Pexec (GEMDOS 75) 69, 161,191,193, 233,256,539, 702 ff. 
Pexec-Cookbook 41 
Pfad, absoluter 160 
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Pfad, aktueller 226 
Pfad, relativer 160 
PH 194 

Physbase (XBIOS 2) 139,152 
PHYSICAL PAGE SIZE (VDI5, 

Escape 99, Opcode 0) 525 
phystop ($42E) 60 
ph_prgflags 194,260 
Picture cell 833 

PIESLICE (VDI 11, GDP 3) 363 
Ping! 65 

Pipeline Refill (68030) 1009 
Pipes 176 
Pixel 833 

Pixelgrößenverhältnis 279 
pixelorientiertes Format 281 

PLACE GRAPHIC CURSOR AT LOCATION (VDI 5, Escape 18) 499 
planeorientiertes Format 281 

Plattenparameter, unveränderliche (SCSI-MODE SENSE) 1113 

Plottertreiber 320, 331 

PMMU (68030) 252,1003, 1015 

Polaroid Palette 327 

Polling 885 

POLY-Modus (MIDI) 917 
Polygonzug 347, 353, 389 
POLYLINE (VDI 6) 347 
POLYMARKER (VDI 7) 349 
POOLFIX3.PRG 182,191,269 
Popup 734 
PORTAB.H 783 
Portabilität 782 

Position Cursor (VT52 ESC Y) 8 

Positionierungsbefehl (FDC) 965 

Post-Mortem 57 

PostScript 321,400 

Potentialtrennung (MIDI) 919 

Pratt, Allan 99, 159 

Prekompensations-Bit (FDC) 969 

PRE VENT/ALLOW MEDIUM REMOVAL (SCSI) 1114 

Privilegverletzung ($20) 52 
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PRN: 161,237 

Process descriptor 186, 244,267, 586, 702 

proc_aregs ($3A4) 58 

proc_dregs ($384) 58 

proc_enum ($3C4) 58 

procjives ($380) 58 

proc_stk ($3CC) 58 

proc_usp ($3C8) 58 

Programm-Flags 194,260 

Programmformat 193 

Programmierrichtlinien 719 

Programmstart 187 

Programmzähler (68000) 793 

Protobt (XBIOS 18) 18, 22,140,161 

Prozeß 184, 266 f. 

Prozeß, aktueller 185 

Prozeßhierarchie 184 

Prozessor-Status 268 

Prozessorsignale (68030) 1004 

_prtabt ($4F0) 67 

Prtblk (XBIOS 36) 67,142, 149 

prt_cnt 49, 66 

Prüfsumme (Disk) 948 

Prüfzeichen (Datenübertragung) 1137 

prv_aux ($512) 70, 143 

prv_auxo ($50E) 70, 143 

prv_lst ($50A) 69,143 

prvjsto ($506) 69, 143 

Pseudo-Sound-Prozessor 866 

PSG (FDC) 955,975 

PSG (par. Schnittstelle) 908 

PSG (Programmable-Sound-Generator) 859 

PSG (ser. Schnittstelle) 893 

PSG(STE) 1308 

PSG (TT) 1211 

PSG-Port 864 

PSG-Register 861 

Pterm (GEMDOS 76) 266 

PtermO (GEMDOS 0) 265 

Ptermres (GEMDOS 49) 173,191, 267 

PfSlN 310 
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Pull-Down 749 

Pulsbreitenmessung (MFP-Timer) 875 
Punkt 279 

Puntaes (XBIOS 39) 42, 144 
PUNJNFO 33,70,172 
pun_ptr ($516) 70, 94,171 
Put pixel ($A001) 310 
_p_cookies ($5A0) 71,73 


Q 

Quarter Screen Buffer 540 
Quotient Byte (68882) 1033 
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R/_W (68030) 1005 

R/_W(ACSI) 984 

R/_W (Megabus) 823 

Rahmenfehler (ser. Datenübertragung) 899 

Rainbow-TOS 166 

RAM(IKBD) 924 

RAM (STE) 1322 

RAM (TT) 1037,1039 

RAM-Chips 796 

RAM erweitern (TT), ST- 1042 

RAM-Speicherbänke (ST) 797 

RAM-Streifen (STE) 1322 

RAM, Altemate 1039 

RAM, batteriegepuffert (TT-Uhr) 1201 

RAM, Single purpose 1042 

RAM, ST- 1039 

ramtop ($5 A4) 71 

ramvalid ($5A8) 71 

Random (XBIOS 17) 145 

RAS 796 

Raster 415,418,421,529 
Rasterformate 280 
Rasterkoordinaten 277, 332 

Rate- and Mode-Control-Register (RMCR) (IKBD) 928 

Rauschgenerator (PSG) 859, 863 

Raw I/O to Standard input/output 219 

Raw input front Standard input 218 

RAWCON 84 

RBUTTON (0x0010) 557 

RC-Koordinatensystem 277, 332 

RCS-Programm 560, 585 

rc_intersect 577 

READ (SCSI) 1101 

READ ADDRESS (FDC) 970 

READ CAPACITY-Kommando (SCSI) 1088 

Read character ffom Standard AUX: 205 

Read character from Standard input 209 

Read character from Standard input, no echo 215 

Read Data (FDC) 952 
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Read edited data from Standard input 212 
Read from file 240 

Read-Modify-Write Cycle (68030) 1005 

Read Sector (ACSI) 995 

READ SECTOR (FDC) 967 

READ TRACK (FDC) 971 

Read/Write (68030) 1005 

Read/Write-Leitung (Megabus) 823 

READ/WRITE MULTIPLE SECTORS (FDC) 967, 973 

Ready (FDC) 953 

READY-LIST 536 

Real-Time-Commands (MIDI) 918 

REASSIGN BLOCKS (SCSI) 1100 

Receive Data Register Full-Bit (ACIA) 914 

Receiver Clock (ST-MFP-USART) 894 

Receiver Overrun-Bit (ACIA) 914 

Receiver-Status-Register (ST-MFP-USART, Adr. SFF FA2B) 895, 898 
Receiver-Status-Register (TT-MFP-USART, Adr. $FF(FF) FAAB) 1071 
Rechteckliste 577 

Record not found-Bit (FDC) 965, 967 
RED (2) 558 
REFILL (68030) 1009 
Register (Kurzübersicht), Hardware- 1349 
Register (PSG) 861 

Registerauswahl (TT-Uhr, Adr. $FF(FF) 8961) 1202 
Registerübersicht (68030) 1010 f. 

Release memory 253 
release velocity (MIDI) 917 
Relozierungsinformationen 195 

REMOVE LAST GRAPHIC CURSOR (VDI5, Escape 19) 500 

Rename file 241 

REPLACE 413,418 

REQ (SCSI) 1077 

Request (SCSI) 1077 

Request joystick availibilty (IKBD $9A) 943 
Request joystick mode (IKBD $94, 

IKBD $95, DCBD $99) 943 
Request mouse availibility (IKBD $92) 943 
Request mouse button action (IKBD $87) 942 
Request mouse mode (IKBD $88, 

IKBD $89, IKBD $8A) 942 
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Request mouse scale (IKBD $8C) 942 
Request mouse threshold (IKBD $8B) 942 
Request mouse vertical Coordinates 
(IKBD $8F, IKBD $90) 943 
Request Sense 992,1090 
Request to send (RTS) 893 
Request to send (SCC) 1157 
Request/Acknowledge-Protokoll (ACSI) 984 
Request/Acknowledge-Protokoll (SCSI) 1073 
RESELECTION-Phase (SCSI) 1079 
Reset 46, 51,59 f. 

RESET (68030) 1008 

RESET (ACSI) 984 

RESET (IBKD $80) 935 

RESET (Megabus) 822 

RESET (SCC) 1162 

RESET (SCSI) 1076 

RESET, 680XX-CPU- 796 

Reset: PC ($4) 51 

Reset: SSP ($0) 51 

Resource Construction Set 552, 701 

Resource-Datei 584 

Response Primitives (68881) 1332 

RESTORE (FDC) 965 

Restore Cursor position (VT52 ESC k) 9 

Restore to Zero (ACSI) 991 

Resume (IKBD $11) 938 

resvalid ($426) 46,59 

resvector ($42A) 46, 59 

RETURN TABLET X AND Y DIMENSIONS (VDI5, Escape 84) 516 
Reverse index (VT52 ESC I) 8 
REVERSE TRANSPARENT 418 
REVERSE VIDEO OFF (VDI 5, 

Escape 14) 495 
REVERSE VIDEO ON (VDI 5, 

Escape 13) 494 
REZERO UNIT (SCSI) 1090 
RGB-Signale (ST(E)) 829 
RGB-Signale (TT) 1048 
Richtungsinformation (Joysticks) 931 
Ring indicator (RI) 56, 893 
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RMC (68030) 1005 
ROM (IKBD) 924 
ROM-Bereich (TT) 1037 
ROM-Cartridge 805 
ROM-Chips, ST- 802 
ROM-TOS 802 

ROM3 sel./ROM4 sei. (Cartridge) 807 
ROMs, TT- 1037 
Root-Pointer (68030) 1016 
Rootsektor 23 
Rotation 401 

ROUNDED RECTANGLE (VDI11, 

GDP8) 373 
Row Adress Strobe 796 
RS-232C-Standard 891 

RS232-Port 55 fi, 70, 83 ff., 98, 127, 146, 154, 161, 205 ff., 869, 891, 894 

RS422 (SCC) 1141 

Rsconf (XBIOS 15) 98,146 

Rsconf(XBIOS 15), Fehler 903 

RSHDR 584 

rsh_fix 733 

rsh_obfix 733 

rsr 147 

RSR (ST-MFP-USART, Adr. $FF FA2B) 898 

RSRCFREE(AES 111) 695,697 

RSRC_GADDR (AES 112) 588,698 

RSRC_LOAD (AES 110) 552, 594,695,697 f„ 701,707 

RSRC_OBFIX (AES 114) 701 

RSRC_SADDR (AES 113) 700 

RSR_TT (TT-MFP-USART, Adr. 

$FF(FF) FAAB) 1071 
RST (SCSI) 1076 
RTARROW (0x0400) 678,693 
rtc_data (TT-Uhr, Adr. $FF(FF) 8963) 1202 
rtc_mr (TT-Ubr, Adr. $FF(FF) 8961) 1202 
RTS (Request to send) 893 
RTS(SCC) 1157 
RTS/CTS-Handshake 127,904 
Rubberbox 653 

Rwabs (BIOS 4) 16,64, 94, 118, 162, 

166 
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RxCLK(ACIA) 911 
RxDATA (ACIA) 911 
RxINT (ACTA) 913 ff. 
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S.A.L.A.D. 307 
Sample (STE) 1294 

SAMPLE KEYBOARD STATE INFORMATION (VDI 128) 455 

SAMPLE MOUSE BUTTON STATE (VDI 124) 448 

Samplefrequenzen (STE) 1294 

Save Cursor position (VT52 ESC j) 9 

savptr ($4A2) 37,57,65 

sav_context ($4AE) 66 

sav_row ($4AC) 9, 65 

Scancode 11, 83, 132, 209, 607, 935 

SCART -Eingang, Anschluß eines ST (E) über einen 830 

SCC (Serial Communications Controller) 1135 

SCC-Baudrate 1165 

SCC-Beispiel initialisierung 1182 

SCC-Control-Reg. Kanal A (Adr. 

$FF(FF) 8C81) 1146 
SCC-Control-Reg. Kanal B (Adr. 

$FF(FF) 8C85) 1146 
SCC-Data-Reg. Kanal A (Adr, 

$FF(FF) 8C83) 1146 
SCC-Data-Reg. Kanal B (Adr. 

$FF(FF) 8C87) 1146 

SCC-DMA-Address-Pointer (ab Adr. $FF(FF) 8C01) 1179 
SCC-DMA-Anschluß 1152 
SCC-DMA-Bytezähler (ab Adr. 

$FF(FF) 8C09) 1179 
SCC-DMA-Einheit 1146, 1178 
SCC-DMA-Kontrollregister (Adr. 

$FF(FF) 8C14) 1179 
SCC-DMA-Register 1179,1365 

SCC-DMA-Restdatenregister (ab Adr. $FF(FF) 8C10) 1179 

SCC-Einbindung im TT 1181 

SCC-Empfänger 1143 

SCC-Empfängersteuerung 1154 

SCC im TT, Betrieb des 1178 

SCC-Kommando Register 1147 

SCC-Loop Mode 1162 

SCC-Loop/Clock Status 1175 
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SCC-Master Interrupt Control 1160 
SCC-Moduseinstellungen für Sender/Empfänger 1155 
SCC-Read-Register 1146, 1172 ff. 

SCC-Sendedatenregister 1160 
SCC-Sender 1145 
SCC-Sendersteuerung 1156 
SCC-Takteinstellung 1165 

SCC-Write-Register 1146, 1150, 1153 ff., 1158 ff., 1162, 1165 1, 1168 

SCC-Write-Register 0 1147 

SCC, Blockdiagramm des 1142 

SCC, Programmierung des 1176 

sccctLa (SCC, Adr. $FF(FF) 8C81) 1146 

scccfljj (SCC, Adr. $FF(FF) 8C85) 1146 

sccdat_a (SCC, Adr. $FF(FF) 8C83) 1146 

sccdafb (SCC, Adr. $FF(FF) 8C87) 1146 

scdmabas (SCC, ab Adr. $FF(FF) 8701) 1179 

scdmacnt (SCC, ab Adr. $FF(FF) 8709) 1179 

scdmactl (SCC, Adr. $FF(FF) 8C14) 1179 

scdmarsd (SCC, ab Adr. $FF(FF) 8710) 1179 

Schattenregister, “memconf801 

Schieberegister im Video-Controller (ST) 836 

Schieberegler 664 

Schleife (MFP-USART) 901 

Schneckennudel 559 

Schnittstelle (IKBD), serielle 927 

Schnittstelle (SCC), Multiprotokoll- 1135 

Schnittstelle als Eingang, parallele 909 

Schnittstelle für Coprozessoren 1019 

Schnittstelle, Hardwaremäßige Realisierung der par. 908 

Schnittstelle, MIDI- 916,919 

Schnittstelle, parallele 55, 69,83 f„ 86,154, 161, 216, 861, 907 

Schnittstelle, serielle 55 f„ 70, 83 ff., 98,127, 146, 154, 161, 205 fl, 869, 891, 894 

Schnittsteilen-Steuerbaustein (SCC) 1135 

Schreib-/Lese-Kopf (Disk) 945, 952 

Schreib-Elektronik (Disk) 945 

Schreibmodus 377 

Schreibschutz 39, 227,229,247 

Schreibvorkompensation (FDC) 969 

Schreibzugriff (VME-Bus) 1188 

SciGraph 756 

SCR (ST-MFP-USART, Adr. $FF FA27) 896 
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scrap 572, 670 ff., 751 
Scrdmp (XBIOS 20) 69,149 
Screen manager 536 f., 599 
screenpt ($45E) 48, 63 
SCRENMGR 536 f., 599 
Scrolling 62 

SCRP_CLEAR (AES 82) 672 

SCRP_READ (AES 80) 670 

SCRP_WRITE (AES 81) 671 

scr_dump ($502) 49,69, 149 

SCR_TT (TT-MFP-USART, Adr. $FF(FF) FAA7) 1070 

SCSI-Adreßregister (TT-SCSI, Adr. $FF(FF) 8789) 1122 

SCSI-Ausgabedaten (TT-SCSI, Adr. $FF(FF) 8781) 1116 

SCSI-Betriebsartenregister (TT-SCSI, Adr. $FF(FF) 8785) 1119 

SCSI-Bus (ACSI) 981 

SCSI-Bus (TT) 1073 

SCSI-Bus-Abschluß 1074 

SCSI-Bus-Anschlußbelegung 1074 f. 

SCSI-Bus-Signale 1076 
SCSI-Buskontrolle 1078 

SCSI-Busstatusregister (TT-SCSI, Adr. $FF(FF) 8789) 1121 
SCSI-Controller (TT) 1073, 1116, 1357 
SCSI-Datenbus (TT-SCSI, Adr. 

$FF(FF) 8781), Aktueller Inhalt des 1116 
SCSI-Datentransfer mit DMA-Unterstützung 1124 
SCSI-DMA-Address-Pointer (TT-SCSI, ab Adr.$FF(FF) 8701) 1125 
SCSI-DMA-Be trieb 1124,1126,1356 
SCSI-DMA-Bytezähler (TT-SCSI, ab Adr. $FF(FF) 8709) 1125 
SCSI-DMA-Controller (TT) 1116 
SCSI-DMA-Kanal 1124 

SCSI-DMA-Kontrollregister (TT-SCSI, Adr. $FF(FF) 8714) 1126 
SCSI-DMA-Register 1125 

SCSI-DMA-Restdatenregister (TT-SCSI, ab Adr. $FF(FF) 8710) 1125 

SCSI-Eingabe-Register (TT-SCSI, Adr. $FF(FF) 878D) 1124 

SCSI-Inititator-Befehlsregister (TT-SCSI, Adr. $FF(FF) 8783) 1117 

SCSI-Interface beim TT 1114 

SCSI-Kommandos 1085 

SCSI-Ports, Programmierung des TT- 1127 

SCSI-Resetreg, Int+Parityfehler (TT-SCSI, Adr. $FF(FF) 878F) 1124 
SCSI-Start DMA-Ausgabe-Register (TT-SCSI, Adr. $FF(FF) 878B) 1123 
SCSI-Start Initiator-DMA-Eingabe-Register (TT-SCSI, Adr. $FF(FF) 878F) 1124 
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SCSI-Start Target-DMA-Eingabe-Register (TT-SCSI, Adr. $FF(FF) 878D) 1123 
SCSI-Statusregister (TT-SCSI, Adr. $FF(FF) 878B) 1122 
SCSI-Target Befehlsregister (TT-SCSI, Adr. $FF(FF) 8787) 1121 
SCSI-Tool 171 
SCU 1195 

SCI) General Purpose Reg, 1 (Adr. $FF 8E09) 1199 

SCU General Purpose Reg. 2 (Adr. $FF 8E0B) 1199 

SCU im TT/MEGA STE, hardwaremäßige Einbindung der 1198 

SCU-Universal-Register 1199 

scu_gpl (SCU, Adr. $FF 8E09) 1199 

scu_gp2 (SCU, Adr. $FF 8E0B) 1199 

SDB 319 

SDLC-Verfahren 1138, 1158 
Search first 245 
Search next 248 

Sector-Counter-Register (Adr. $FF 8604) 818,977 

Seedfill ($A00F) 320 

SEEK (ACSI) 995 

SEEK(FDC) 965,978 

SEEK (SCSI) 1102 

Seek file pointer 242 

seekrate ($440) 60,63,116 

Sektor 118 ff. 

Sektor-Header (Disk) 947 
Sektorbeginn (Disk) 947 
Sektoren, logische 94 
Sektoren/Spur (ACSI) 997 
Sektorgröße (Disk) 947, 956 
SEL (SCSI) 1076 
Select (SCSI) 1076 

SELECT PALETTE (VDI5, Escape 60) 510 
SELECTABLE (0x0001) 556 
SELECTED (0x0001) 558,663 
SELECTION-Phase (SCSI) 1079 
Selektion 762 

Sende-Schieberegister (ACIA) 911 
Sendepuffer (MFP-USART) 895 
Sender (ACIA) 911 
Senderegister (ACIA) 911 
Senderegister (IKBD) 927 
Senderegister (MFP-USART) 895 
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Senderegister (MIDI-ACIA, Adr. 

$FF FC04) 915 

Senderegister (Tastatur-ACIA, Adr. 

$FF FC02) 915 

Sendeschieberegister (MFP-USART) 895 
Sendeschieberegister (SCC) 1145 
Sendetakt (ST-MFP-USART) 894 
Sense-Daten (SCSI) 1090, 1093, 1095 
Separator 750 
Sequenzer 916 

SERIAL 1 (TT-MFP) 1062,1070 

SERIAL 2 (SCC) 1141 

SERIAL 2 (TT-PSG) 1212 

Serial Communications Controller (Übersicht) 1366 

Serial-Communications-Element (IKBD) 927 

Serial Port C (TT) 1061 

Seriennummer 92, 140 

Set absolute mouse positioning (IKBD $09) 936 
SET ATTRIBUTE SHADOW OFF (51) 524 
SET ATTRIBUTE SHADOW ON (50) 524 
Set background color (VT52 ESC c) 8 

SET CAMERA FILM TYPE AND EXPOSURE TIME (VDI5, Escape 91) 518 
SET CHARACTER BASELINE VECTOR (VDI 13) 401 
SET CHARACTER HEIGHT, ABSOLUTE MODE (VDI 12) 396 
SET CHARACTER HEIGHT, POINTS MODE (VDI 107) 398 
SET CLIPPING RECTANGLE (VDI 129) 346 
SEI' COLOR REPRESENTATION 
(VDI 14) 382 
Set current directory 226 
Set date 272 
Set default drive 225 
SetDTA 244 

SET FIEL COLOR INDEX (VDI 25) 

411 

SET FILLINTERIOR INDEX (VDI 23) 408 

SET FILL PERIMETER VISIBILITY (VDI 104) 412 

SET FILL STYLE INDEX (VDI 24) 409 

Set fire button monitoring (IKBD $18) 939 

Set foreground color (VT52 ESC b) 8 

SET GRAPHIC TEXT ALIGNMENT (VDI 39) 406 

SET GRAPHIC TEXT COLOR INDEX (VDI 22) 403 
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SET GRAPHIC TEXT SPECIAL EFFECTS (VDI106) 404 

SET INPUT MODE (VDI33) 425 

Set joystick event reporting (IKBD $14) 938 

Set joystick interrogation mode (IKBD $15) 939 

Set joystick keycode mode (IKBD $19) 939 

Set joystick monitoring (IKBD $ 17) 939 

SET LINE OFFSET (VDI 5, Escape 101) 529 

Set mouse button action (IKBD $07) 936 

SET MOUSE FORM (VDI 111) 443 

Set mouse keycode mode (IBKD $A) 

937 

Set mouse scale (IKBD $C) 937 
Set mouse threshold (IKBD $B) 937 
SET NO LINE STYLE (49) 524 
SET POLYLINE COLOR INDEX 
(VDI 17) 388 

SET POLYLINE END STYLES (VDI 108) 389 

SET POLYLINE LINE TYPE (VDI 15) 384, 386 

SET POLYLINE LINE WIDTH (VDI 16) 387 

SET POLYMARKER COLOR INDEX (VDI 20) 395 

SET POLYMARKER HEIGHT (VDI 19) 393 

SET POLYMARKER TYPE (VDI 18) 391 

Set relative mouse position reporting (IKBD $08) 936 

SET TABLET ALIGNMENT (VDI 5, Escape 85) 517 

SET TABLET AXIS RESOLUTION IN LINES (VDI 5, Escape 82) 514 

SET TABLET AXIS RESOLUTION IN LINES/INCH (VDI 5, Escape 81) 513 

SET TABLET X AND Y ORIGIN (VDI 5, Escape 83) 515 

SET TEXT FACE (VDI 21) 402 

Set time 273 

SET USER-DEFINED FILL PATTERN (VDI 112) 413 

SET USER-DEFINED LENE STYLE PATTERN (VDI 113) 386 

SET WRITING MODE (VDI 32) 377 

Set Y=0 at bottom (IKBD $F) 938 

Set Y=0 at top (IKBD $10) 938 

SET/CLEAR TONE MUTING FLAG (VDI 5, Escape 62) 512 

Setcolor (XBIOS 7) 150 

Setexc (BIOS 5) 50,96,197 

Setpalette (XBIOS 6) 151 

Setprt (XBIOS 33) 11, 84, 149, 154,217 

Setscreen (XBIOS 5) 63, 152,183 

Settime (XBIOS 22) 153 
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Set_Evnt_Mask 740 
SHADOWED (0x0020) 558,663 
SHDRIVER.SYS 24 f. 

Shell-Puffer 586 
_shell_p ($4F6) 68 
SHEL_ENVRN (AES 125) 191, 539, 

708 

SHEL_FIND (AES 124) 539,695,707 
SHEL_GET (AES 122) 705 
SHELJPUT (AES 123) 706 
SHEL_RDEF (AES 126) 710 
SHELJREAD (AES 120) 702,707 
SHEL_WDEF (AES 127) 711 
SHEL_WRTTE (AES 121) 599, 702 f. 
Shift-Mode-Register (ST(E)), Adr, 

$FF 8260 107,838 
Shift-Mode-Register (TT, Adr. 

$FF(FF) 8260), ST(E)- 1056 
Shift-Mode-Register (TT, Adr. 

$FF(FF) 8262), TT- 1057 
Shifter 62, 156, 788, 836, 841, 1053, 1057 
shiftmd (TT, Adr. $FF(FF) 8260) 1057 
shiftJTT (TT, Adr. $FF(FF) 8262) 1057 
Short-Access (VME-Bus) 1188 
SHOW CURSOR (VDI122) 446 
Show mouse ($A009) 317 
Shrink size of allocated block 254 
Shugart-Bus 949,953 

Sicherungsverfahren (Datenübertragung) 1137 

Side select (FDC) 951,955,975 

Side select (TT-PSG) 1211 

Signalleitungen (FDC) 950 

SIMM (STE) 1322 

Single-Chip-Modus (IKBD) 924 

Single Real (68882) 1023, 1027 

SIZ0/SIZ1 (68030) 1005 

SIZE (0x0020) 678,693 

Skew (BUTTER, Adr. $FF 8A3D) 852 

Slave (VME-Bus) 1187 

_SLM 81,531 

SLM-Laserdrucker 342 
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Sl_arrow 737 
Sl_dragx 738 
SLdragy 738 
Sl_size 735 
Sl_x 736 
Sl_y 736 

Small Computer Systems Interface (TT) 1073 
SMUDGE-Bit (BLITTER, Adr. 

$FF 8A3C) 854 
_SND 80 

sndadrhi (STE, Adr. $FF 8908) 1297 
sndadrlo (STE, Adr. $FF 890C) 1297 
sndadrmi (STE, Adr. $FF 890A) 1297 
sndbashi (STE, Adr. $FF 8902) 1297 
sndbaslo (STE, Adr. $FF 8906) 1297 
sndbasmi (STE, Adr. $FF 8904) 1297 
sndendhi (STE, Adr. $FF 890E) 1297 
sndendlo (STE, Adr. $FF 8912) 1297 
sndendmi (STE, Adr. $FF 8910) 1297 
sndmactl (STE, Adr. $FF 8900) 1297 
sndmode (STE, Adr. $FF 8920) 1297 
Software-EOI-Modus (MFP) 888 
Sound-Chip (FDC) 955 
Sound-DMA-Control-Reg. (STE, Adr. 

$FF 8900) 1297 
Sound-DMA-Modul (STE) 1296 
Sound-Mode-Control (STE, Adr. $FF 8920) 1297 
Soundchip (par. Schnittstelle) 908 
Soundchip (PSG) 80, 105, 123, 138 
Soundchip, hardwaremäßige Einbindung des 860 
Sounderzeugung (STE) 1294 
Soundgenerator (PSG) 859,1359 
SOUNDSHIFTER (TT) 1212 

Source-Address-Register (BLITTER, Adr. $FF 8A24) 851 
Source-Buffer (BLITTER) 852 

Source-X-Increment-Register (BLITTER, Adr. $FF 8A20) 851 

Source-Y-Increment-Register (BLITTER, Adr. $FF 8A22) 851 

Speicher, virtueller 1014 

Speicheraufteilung des ST 795 

Speicherbestückung (ST) 796 

Speichererweiterung (ST) 799 
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Speicherkapazität (Floppy-Disk) 945 

Speicherkonfiguration (ST) 799, 1349 

Speicherraumreservierungen, Megabus- 825 

Speichertest, ST- 800 

Speicherverwaltung 36, 179 

Spur 38,114,945 

Spur im Speicher (Disk) 971 

Spur suchen (FDC) 965 

Spurwechsel (Disk) 946 

Spuranfang (Disk) 952 

Spuren (Disk) 945 

Spurious Interrupt ($60) 53 

Spurwechselzeit 116,959, 961 

Src_Addr (BUTTER, Adr. $FF 8A24) 851 

Src_Yinc (BUTTER, Adr. $FF 8A22) 851 

SRP (68030) 1016 

Ssbrk (XBIOS 1) 155 

sshiftmd ($44C) 62 

SSP 268 

ST-Betriebsmodi (TT-Video) 1048 
ST-Blitter 842 

ST-High-Resolufion (TT) 1048 
ST-Low-Resolution (TT) 1049 
ST-Magazin 82 

ST-Medium-Resolution (TT) 1049 

ST-MFP (TT) 1061 

ST-RAM (TT) 1039 

ST-RAM-Erweiterungskarte (TT) 1040 

Stack 188,268 

Stack-Pointer (68000) 793 

Stackpointer (68030) 1010 

Stacy, LCD-Steuerung 1351 

Standard Access (VME-Bus) 1188 

Standardformat 415,421 

Standardkanal 174, 206 f., 216, 233 f. 

Standardzugriffspfad 696 

Stapelzeiger (68000) 793 

START DRAW AREA PRIMITIVE (80) 524 

START GROUP (10) 524 

Start/Stop-Betrieb (SCC) 1136,1142 

START/STOP UNTT (SCSI) 1113 
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Startadresse des FAST-RAM 1045 

Startbit (MFP-USART) 892 

Startbit (MIDI) 919 

Startbit (SCC) 1136 

Startupcode 189, 541 

Startwert, Supervisor-Stack-Pointer- 796 

State Frame (68882) 1031 

Status 266 f. 

STATUS (68030) 1009 

Status der Sende- und Empfangsbuffer (SCC) 1169 

Status inquiries (IKBD $87-$9A) 941 

STATUS-Phase (ACSI) 984, 989 

STATUS-Phase (SCSI) 1080,1082 

Statusbyte (ACSI) 989, 998 

Statusbyte (SCSI) 1082 

Statusbytes (MIDI) 917 

Statuspaket (IKBD) 942 

Statusregister (68000) 52,793 

Statusregister (68030) 1010 

Statusregister (ACIA) 911, 914, 921 

Statusregister (MIDI-ACIA, Adr, 

$FF FC04) 915 

Statusregister (Tastatur-ACIA, Adr. 

$FF FC00) 915 
stdaux 173, 237 
stderr 176 

stdin 173, 209 f., 212,218 f-, 233 f„ 237 

stdout 173, 210 f„ 214, 219, 233 f„ 237 

stdpm 173, 237 

STE, Hardware 1285 

Steckerformat (Disk) 953 

Step (FDC) 952 

Step direction (FDC) 952, 962 

Step-Impuls (FDC) 962, 966 

STEP IN (FDC) 966 

STEP OUT (FDC) 966 

Steprate (FDC) 116, 959, 961 

Stereo-Modus (STE) 1296 

STERM (68030) 1006 

Steuerpegel (FDC) 956 

Steuerregister (AC1A) 912 
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Steuerregister (MIDI-ACIA, Adr. 

$FF FC04) 915 

Steuerregister (Tastatur-ACIA, Adr. 

$FF FCOO) 915 

Steuersignale für die Floppy-Disk-Steuerung (PSG) 861 
Steuerung, FDC/ACSI- 816 
Steuerungsverfahren (SCC) 1137 f. 

Steuerungsverfahren (SCC), synchrone/asynchrone 1136 

STOP (3) 644 

Stopbit (MFP-USART) 892 

Stopbit (MIDI) 919 

Stopbit (SCC) 1136,1156 

Stopbits (MFP-USART), Anzahl 896 

STROBE (par. Schnittstelle) 907 

Stromsteuerung (MIDI) 921 

Stromversorgungsanschlüsse (VME-Bus) 1193 

Struktur (Disk) 947 

Super (GEMDOS 32) 268 

Supervisor-Betrieb (68030) 1010 

Supervisor-Modus 52, 156, 268, 793 

Supervisor-Root-Pointer (68030) 1016 

Supexec (XBIOS 38) 156 

Sversion (GEMDOS 48) 269 

_SWI 80 

swv_vec ($46E) 48, 63 
Symboltabelle 195 
Sync-Mode-Register (ST(E)), Adr. 

SFF820A 839 

Sync-Mode-Register (TT, Adr. $FF(FF) 820A), ST(E)- 1055 
Synchronbetrieb (SCC) 1136,1142,1155 
Synchronimpulse (TT) 1048 
Synchronisation der Datenübertragung (ACSI) 987 
Synchronisationsbyte (Disk) 970 
Synchronisationssignale (ST(E)-Video) 829 

Synchronous-Character-Register (ST-MFP-USART, Adr. $FF FA27) 896 

Synchronous-Character-Register (TT-MFP-USART, Adr. $FF(FF) FAA7) 1070 

Synchronous Data Link Control 1138 

Synchronous Termination (68030) 1006 

Synchronzeichen (MFP-USART) 891,896 

Synchronzeichen (SCC) 1137 
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syncmode (TT, Adr. $FF(FF) 820A) 

1056 

Synthesizer 916 
Syquest 32,34,1114 
_sysbase ($4F2) 11,67, 91, 181, 270 
SYSCLK (VME-Bus) 1192 
SYSFAIL (VME-Bus) 1192 
SYSRESET (VME-Bus) 1192 f. 

System Commands (MIDI) 920 
System Control Unit (SCU) 1195,1367 
System Int. Mask-Register (SCU, Adr. 

$FF 8E01) 1195 

System Int. Status-Register (SCU, Adr. $FF 8E03) 1196 
System-RESET (Megabus) 823 
System Software Int. (SCU, Adr. 

$FF 8E05) 1197 
System-Timer 97 
system() 68 

Systembus des MEGA ST 820 
Systemdatei 227, 229, 247 
Systemdatum 270, 272 
Systemdiskette 801 
Systeminitialisierung 44 
Systemtakt (68030) 1003 
Systemtakt (IKBD) 925 
Systemtakt (STE) 1313 
Systemvariablen 796 
Systemzeichensätze 287, 666 
Systemzeit 129, 231,271, 273 
sysjnt (SCU, Adr.$FF 8E05) 1197 
sys_mask (SCU, Adr.SFF 8E01) 1195 
sys_stat (SCU, Adr.SFF 8E03) 1196 
s_data (TT-SCSI, Adr. $FF(FF) 8781) 1116 
s_dmastat (TT-SCSI, Adr. $FF(FF) 878B) 1122 
sjcr (TT-SCSI, Adr. $FF(FF) 8783) 1117 
sjdstat (TT-SCSI, Adr. $FF(FF) 8789) 1121 
sjnircv (TT-SCSI, Adr. $FF(FF) 878F) 1124 
s_mode (TT-SCSI, Adr. $FF(FF) 8785) 1119 
s_targrcv (TT-SCSI, Adr. $FF(FF) 878D) 1123 
s_tcr (TT-SCSI, Adr. $FF(FF) 8787) 

1121 
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T 

Tabellen-Deskriptor (68030) 1015 

TACR (ST-MFP, Adr. $FF FA 19) 879 

TACRJTT (TT-MFFP, Adr. $FF(FF) FA99) 1065 

TADR (MFP, Adr.SFF FA1F) 878 

TADR_TT (TT-MFP, Adr. $FF(FF) FA9F) 1066 

TAI (par. Schnittstelle) 910 

TAI(Timer-A-InputdesMFP) 875 

Takt (68030) 1009 

Takt (68882) 1020 

Taktflanke (FDC), fehlende 970 

Taktfrequenz (ACIA) 911 

Taktfrequenz (MFP-USART) 897 

Taktquelle für Kanal A/B (SCC) 1141, 1165 

Taktrückgewinnung (Datenübertragung) 1139 f. 

Taktrückgewinnung (SCC) 1167 

Taktumschaltung (STE) 1314 

Target (ACSI) 982,990 

Target (SCSI) 1073 

Task (68030) 1014 

Tastatur 129,131,219,922 

Tastatur (MEGA ST(E)), Anschlußbild der 932 

Tastatur (ST) (Schaltbild) 930 

Tastatur-ACIA (Übersicht) 1379 

Tastatur-ACIA, Interrupt von 870 

Tastatur-Empfangsregister (Tastatur-ACIA, Adr. $FF FC02) 915 
Tastatur-Ereignis 543 

Tastatur-Senderegister (Tastatur-ACIA, Adr. $FF FC02) 915 

Tastatur-Statusregister (Tastatur-ACIA, Adr. $FF FC00) 915 

Tastatur-Steuerregister (Tastatur-ACIA, Adr. $FF FCOO) 915 

Tastaturbelegung 100,758 

Tastaturchip 56, 84, 86, 124,129, 922 

Tastaturmatrix 929,931 

Tastaturprozessor (IKBD) 923 

Tastaturzeichen (IKBD) 929 

Tastencode 11, 83, 132,209, 607 

Tastendynamik (MIDI) 917 

TA_ASCENT (2) 407 

TA_BASELINE (0) 407 

TA_BOTTOM (3) 407 
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TA_CENTER (1) 407 
TA_DESCENT (4) 407 
TA_HALF (1) 407 
TAJLEFT (0) 407 
TA_RIGHT (2) 407 
TA_TOP (5) 407 

TBCR (ST-MFP, Adr. $FF FA 1B) 880 
TBCRJTT (TT-MFP, Adr. $FF(FF) FA9B) 1065 
TBDR (ST-MFP, Adr. $FF FA21) 879 
TBDR_TT (TT-MFP, Adr. 

$FF(FF) FAA1) 1066 
TBI (Timer-B-Input des MFP) 875 
TCDCR (ST-MFP, Adr. $FF FA1 D) 880 
TCDCR_TT (TT-MFP, Adr. 

$FF(FF) FA9D) 1066 
TCDR (ST-MFP, Adr. $FF FA23) 879 
TCDR_TT (TT-MFP, Adr. 

$FF(FF) FAA3) 1066 
TDDR (ST-MFP, Adr. $FF FA25) 879 
TDDR_TT (TT-MFP, Adr. 

$FF(FF) FAA5) 1066 
TEDINFO 559,561 
Terminate and stay resident 267 
Terminate Process 265 f. 

Test Drive Ready (ACSI) 991 

TEST UNIT READY (SCSI) 1089 

TEXT (VDI 8) 186, 351,401, 406,441, 466, 468,470 

Textattribut 375, 404 

TextBlt (Text Block Transfer) ($A008) 315 

Texteffekte 375, 404 

TE_CNTR (2) 560 

TEJLEFT (0) 560 

TEJUGHT(l) 560 

TFJLIGHTENED (0x02) 405 

TFJMORMAL (0x00) 405 

TF_OUTLINED (0x10) 405 

TF_SHADOWED (0x20) 405 

TF_SLANTED (0x04) 405 

TFJTHICKENED (0x01) 405 

TF_UNDERLINED (0x08) 405 

Tgetdate (GEMDOS 42) 231,270 ff. 
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Tgettime (GEMDOS 44) 231,271,273 

themd ($48E) 65 

the_env ($4BE) 66 

Tickcal (BIOS 6) 61,97 

Time-of-day clock set (IKBD $ 1B) 940 

Timer (IKBD) 925 

Timer (TT-MFP) 1065 

Timer-A-Control-Register (ST-MFP, Adr. $FF FA19) 879 
Timer-A-Control-Register (TT-MFP, Adr. $FF(FF) FA99) 1065 
Timer-A-Data-Register (MFFP, Adr. 

$FF FA1F) 878 

Timer-A-Data-Register (TT-MFP, Adr. $FF(FF) FA9F) 1066 

Timer-A-Input (MFP) 875 

Timer-A-Input (par. Schnittstelle) 910 

Timer-A-Input (TT-MFP) 1065 

Timer-A-Interrupts (STE-Sound) 1299 

Timer-B-Control-Register (ST-MFP, Adr. $FF FA1B) 880 

Timer-B-Control-Register (TT-MFP, Adr. $FF(FF) FA9B) 1065 

Timer-B-Data-Register (ST-MFP, Adr. $FF FA21) 879 

Timer-B-Data-Register (TT-MFP, Adr. $FF(FF) FAA1) 1066 

Timer-B-Input (MFP) 875 

Timer-B-Input (TT-MFP) 1065 

Timer-Betriebsarten, MFP- 873 

Timer-C (TT-MFP) als SCC-Taktgeber 1066 

Timer-C-Data-Register (ST-MFP, Adr. $FF FA23) 879 

Timer-C-Data-Register (TT-MFP, Adr. $FF(FF) FAA3) 1066 

Timer C-Interrupt 866 

Timer-C/D-Control-Register (ST-MFP, Adr. $FF FAID) 880 
Timer-C/D-Control-Register (TT-MFP, Adr. $FF(FF) FA9D) 1066 
Timer-Control/Status-Register (TCSR) (IKBD) 926 
Timer-D-Data-Register (ST-MFP, Adr. $FF FA25) 879 
Timer-D-Data-Register (TT-MFP, Adr. $FF(FF) FAA5) 1066 
Timer-D-Output (ST-MFP-USART) 894 
Timer-Data-Register (MFP) 874 f. 

Timer-Ereignis 543 
Timer-Interrupt (MFP) 877 
Timer-Programmierung 878 
Timer, ST-MFP- 872 
Timerinterrupt 445 

Timing-Logik, ST-Video-Controller- 837 
_timr_ms ($442) 61,97 
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Tonerzeugung (PSG) 862 

Tongenerator-Control-Register (PSG) 863 

Tonhöhe-Rauschen-Register (PSG) 863 

Tonsignal “zusammenbauen” (STE) 1294 

Tonsignal, externes (ST) 866 

TOS 1.02 802 

TOS 1.04 166 

TOS14FIX.PRG 904 

TOUCHEXIT (0x0040) 557,652 

TPA 187 

Trace ($24) 52 

Track 38,114,945 

Track 00 (FDC) 952,965 

Track-Layout (Disk) 947, 972 

Track-Register (FDC) 962 

Transfer Size (68030) 1005 

Transferlänge (SCSI) 1088, 1091, 1101,1112 

Transferphase (SCSI) 1080 

Transferrate (TT-SCSI) 1116 

TRANSFORM FORM (VDI110) 415,421 

Transform mouse ($A00B) 318 

Translation Control Register (TC) (68030) 1017 

Transmit/Receive-Control and Status-Register (TRCSR) (IKBD) 928 

Transmitter Clock (ST-MFP-USART) 894 

Transmitter-Status-Register (ST-MFP-USART, Adr. $FF FA2D) 895,900 
Transmitter-Status-Register (tsr, Adr. 

$FF FA2D) 147,190 

Transmitter-Status-Register (TT-MFP-USART, Adr. $FF(FF) FAAD) 1071 
TRANSPARENT 418 
Transparent Translation Register 

(TT0/TT1) 1014 
TRAP #0 ($80) 54 
TR AP #1 ($84) 54 
TRAP #13 ($B4) 54 
TRAP #14 ($B8) 55 
TRAP #15 (SBC) 55 
TRAP #2 ($88) 54 
Treiberstufen (FDC) 956 
trpl4ret ($486) 65 
True-Color 288 
Tsetdate (GEMDOS 43) 272 
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Tsettime (GEMDOS 45) 273 

tsr ($FF FA2D) 147,190 

TSR (ST-MFP-USART, Adr.$FF FA2D) 900 

TSRjrr (1T-MFP-USART, Adr. 

$FF(FF) FAAD) 1071 
TT-Cartridgepoit 1045 
TT-DMA-Soundteil 1213 
TT-FAST-RAM-Memory Controller Unit 1044 
TT-Grafik-Betriebsarten 1049 
TT-MFP 1063, 1374 
TT-RAM 182, 194, 1039, 1042 
TT-Uhrenchip 1201 f. 

TTFMCU 1044 

TTSCU (68882) 1019 

TT_colX, (ab Adr. $FF(FF) 8400) 1058 

tt_dmabas (TT-SCSI, ab Adr. 

$FF(FF) 8701) 1125 
tt„dmacnt (TT-SCSI, ab Adr. 

$FF(FF) 8709) 1125 

tt_dmactl (TT-SCSI, Adr. $FF(FF) 8714) 1126 
tt_dmarsd (TT-SCSI, ab Adr. 

$FF(FF) 8710) 1125 
Turbo-DOS 269 
Turbolader 813,818 
TxCLK(ACIA) 911 
TxDATA (ACIA) 911 
TxINT(ACIA) 913 
Typenraddrucker 154 
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u 

ucr ($FF FA29) 147 

UCR (ST-MFP-USART, Adr. $FF FA29) 896 
UCR_TT (TT-MFP-USART, Adr. 

$FF(FF) FAA9) 1070 

UDR (ST-MFP-USART, Adr. $FF FA2F) 903 
UDR_TT (TT-MFP-USART, Adr. 

$FF(FF) FAAF) 1071 
UDS (68000) 793,807 
UDS (Megabus) 823 

Übertragungsprotokoll (STE-MICROWIRE(TM)-Interface) 1309 

Übertragungsrate (ser. Schnittstelle) 903 

Uhr im IKBD-Chip 940 

Uhrenchip (MEGA ST(E)) 1325 

Uhrenchip (TT) 1201 1 ,1362 

Uhrenchip-Register (MEGA ST(E)) 

1327 

Uhrenchips (TT-Uhr), Programmierung des 1208 
Uhrenregister (TT) 1202 
Uhrzeit 129,231,271,273 
Umrahmung 412 
Umriß 655 

Umschalttasten 11, 455 
Undraw sprite ($A00C) 318 

Universal Synchronous/ Asynchronous Receiver/ Transmitter, ST-MFP- 894 

UNLOAD FONTS (VDI120) 345 

Unterbrechungen (ST(E)) 840 

Unterbrechungsmaske (CPU) 881 

UPARROW (0x0040) 678,693 

UPDATE METAFILE EXTENTS (VDI 5, Escape 98) 521 
UPDATE WORKSTATION (VDI 4) 341,502 
Upper-Data-Strobe (68000) 793 
Upper-Data-Strobe (Megabus) 823 
usage count 263 

USART-Control-Register (ST-MFP-USART, Adr. $FF FA29) 896 
US ART-Control-Register (TT-MFP-USART, Adr. $FF(FF) FAA9) 1070 
USART-Control-Register (ucr, Adr. 

$FF FA29) 147 

USART-Data-Register (ST-MFP-USART, Adr. $FF FA2F) 903 
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USART-Data-Register (TT-MFP-USART, Adr. $FF(FF) FAAF) 1071 

USART-Empfänger (MFP) 895 

USART-Sender (MFP) 895 

USART, ST-MFP- 894 

User-Modus (68000) 268, 793 

User-Modus (68030) 1010 

USERBLK 564 

USP 268 
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V 

V-Signal bei Colorbetrieb (ST(E)) 829 
V-Synchronimpulse (ST(E)) 838 
Valid Memory Address (Megabus) 824 
Valid Peripheral Address (Megabus) 824 
_vbclock ($462) 48, 63 

VBlank 21,48, 53, 62 f., 66, 151, 156, 840, 866, 882 
_ vblqueue ($456) 49, 62, 66 
vblsem ($452) 48,62f. 

_vbl_list ($4CE) 66 

vcounthi (Adr. $FF 8205) 840, 1055,1317 

vcountlow (Adr. $FF 8209) 840, 1055, 1317 

vcountmid (Adr. $FF 8207) 840, 1055, 1317 

VDI-Bindings 296 f. 

vdi() 299 

VDIESC 310 

_VDO 80 

Vektor Base Register (VBR) (68030) 1010 
Vektomummer (MFP) 888 
Vektornummer (SCC) 1153 f. 

Vektomummer (TT-MFP) 1067 
Vektomummer (VME-Bus) 1191,1193 
Verify 61,962,966 

Verknüpfungsmöglichkeiten (BUTTER) 843 

Versorgungs- und Hilfsleitungen (VME-Bus) 1186 

Vertical-Blank-Interrupt 21,48, 53, 62 f., 66, 151,156, 829, 840 

Vertical-Blank-Interrupt (ST(E)) 829, 840 

Verzögerungs-Timer (MFP) 874 

vex„butv (VDI 125) 450 

vex_curv (VDI127) 453 

vex_motv (VDI 126) 452 

vex_timv(VDI 118) 445 

VGA-Monitor (TT) 1048 

Video-Address-Counter (ST) 840 

Video-Address-Counter (STE) 1316 f. 

Video-Address-Counter (TT) 1055 
Video-Addr.-Counter High-Byte (Adr. 

$FF 8205) 840 

Video-Addr.-Counter Low-Byte, (Adr. 

SFF8209) 840 
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Video-Addr.-Counter Mid-Byte (Adr. 

$FF 8207) 840 
Video-Base-Register (ST) 839 
Video-Base-Register (STE) 1285, 1316 
Video-Base-Register (TT) 1055 
Video-Controller (Megabus) 822 
Video-Controller, Prinzipschaltbild des ST- 837 
Video-Hardware (STE) 829 
Videoanschluß (TT) 1047 
Videocontroller 80 
Videocontroller, ST- 835,1349 
Videocontroller, TT- 1053 
Videohardware (STE) 1285,1313 
Videohardware (TT) 1047 
Videosignale mischen (STE) 1313 
Virenprogramme 21 
Virgin-Byte (ACSI) 994 
VME-Bus 1185 

VME-Bus im TT/MEGA STE, Hardwaremäßige Realisierung des 1194 

VME-Bus Int. Level 3 erzeugen (SCU, Adr. $FF 8E07) 1198 

VME-Bus Int. Mask-Register (SCU, Adr. $FF 8E0D) 1196 

VME-Bus Int. Status-Register (SCU, Adr. $FF 8E0F) 1197 

VME-Bus-Interruptquellen (SCU) 1197 

VME-Bus-Standard, Einschränkungen gegenüber dem 1192 

VME-Bus-Stecker 1186 

VME-Bus, Lesezugriff 1188 

VME-Buskonzept 1185 

vme_int (SCU, Adr.$FF 8E07) 1198 

vme_mask (SCU, Adr.$FF 8E0D) 1196 

vme_stat (SCU, Adr.$FF 8E0F) 1197 

vm_coords (VDI5, Escape 99, Opcode 1) 324, 526 

vm_filename (VDI 5, Escape 100) 528 

vm_pagesize (VDI 5, Escape 99, 

Opcode 0) 324, 525 
Voice-Commands (MIDI) 917 
volume name 227,229, 247 
Volume/Tone-Controller LMC1992 (STE) 1308, 1311 
Vorteiler (MFP) 874, 879, 897 
VPA (Megabus) 824 
vqf_attributes (VDI 37) 465 
vqin_mode (VDI 115) 476 
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vql_attributes (VDI 35) 461 

vqm_attiibutes (VDI 36) 463 

vqp_filmname (VDI 5, Escape 92) 518 f. 

vqt_attributes (VDI 38) 466 

vqt_extent (VDI 116) 468 

vqt_fontinfo (VDI 131) 477 

vqtjustified (VDI 132) 480 

vqt_name (VDI 130) 472 

vqt_width (VDI 117) 470 

vq_cellarray (VDI 27) 474 

vq_chcells (VDI 5, Escape 1) 482 

vq_color (VDI 26) 308,459 

vq_curaddress (VDI 5, Escape 15) 496 

vq_extnd (VDI 102) 283, 297, 307,456 

vq_gdos() 289,343 

vq_key_s (VDI 128) 455 

vq_mouse (VDI 124) 448 

vq_scan (VDI 5, Escape 24) 322, 506 

vq_tabstatus (VDI 5, Escape 16) 497 

vqjdimensions (VDI 5, Escape 84) 516 

VR (ST-MFP, Adr. $FF FA17) 888 

vro_cpyfm (VDI 109) 415 

vrq_choiee (VDI 30) 435 

vrqJocator (VDI 28) 427 

vrq_string (VDI 31) 439 

vrq_vahiator (VDI 29) 431 

vrt_cpyfm (VDI 121) 418 

vr_recfl (VDI 114) 358 

vr_tmfm(VDI 110) 421 

VRjrr (TT-MFP, Adr. $FF(FF) FA97) 1069 

vsc_expose (VDI 5, Escape 93) 520 

vsc_form (VDI 111) 443 

vsf_color (VDI 25) 411 

vsfjnterior (VDI 23) 408,413 

vsf_perimeter (VDI 104) 412 

vsf_style (VDI 24) 409 

vsf_udpat (VDI 112) 413 

vsin.jnode (VDI 33) 425 

VSLIDE (0x0100) 678,693 

vsLcolor (VDI 17) 388 

vsl_ends (VDI 108) 389 
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vsl_type (VDI15) 384 

vsl_udsty (VDI113) 386 

vsLwidth (VDI 16) 387 

vsm_choice (VDI 30) 437 

vsm.color (VDI 20) 395 

vsmjieight (VDI 19) 393 

vsm_locator (VDI 28) 429 

vsm_string (VDI 31) 441 

vsm_type (VDI 18) 391 

vsm_valuator (VDI 29) 433 

vsp_film (VDI 5, Escape 91) 518 

vst_alignment (VDI 39) 406 

vst_color (VDI 22) 403 

vst_effects (VDI 106) 404 

vstj'ont (VDI 21) 402 

vst_height (VDI 12) 396 

vstjoadjonts (VDI 119) 287, 289, 343,472 

vst_point (VDI 107) 398 

vst_rotation (VDI 13) 401 

vst_unload_fonts (VDI 120) 345 

vswr_mode (VDI 32) 377 

Vsync (XBIOS 37) 156 

vs_clip (VDI 129) 346 

vs„color (VDI 14) 382 

vs_mute (VDI 5, Escape 62) 512 

vs_palette (VDI 5, Escape 60) 510 

VT52-Emulator 7 

vt_alignment (VDI 5, Escape 85) 517 
vt_axis (VDI 5, Escape 82) 514 
vt_origin (VDI 5, Escape 83) 515 
vt_resolution (VDI 5, Escape 81) 513 
v_alpha_text (VDI 5, Escape 25) 322,508 
v_arc (VDI 11, GDP 2) 361 
v_bar (VDI 11, GDP 1) 360 
_v_bas_ad ($44E) 48,62 
v_bit_image (VDI 5, Escape 23) 504 
v_cellarray (VDI 10) 355 
v_circle (VDI 11, GDP 4) 365 
v_clear_disp_list (VDI 5, Escape 22) 503 
v_clrwk (VDI 3) 340 
v_clsvwk(VDI 101) 339 
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v_clswk (VDI2) 325,336 
v_contourfill (VDI 103) 357 
v_curaddress (VDI 5, Escape 11) 492 
v_curdown (VDI 5, Escape 5) 486 
v_curhome (VDI 5, Escape 8) 489 
v_curleft (VDI 5, Escape 7) 488 
v_curright (VDI 5, Escape 6) 487 
v_curtext (VDI 5, Escape 12) 493 
v_curup (VDI 5, Escape 4) 485 
v_dspcur (VDI 5, Escape 18) 499 
v_eeol (VDI 5, Escape 10) 491 
v_eeos (VDI 5, Escape 9) 490 
v_ellarc (VDI 11, GDP 6) 369 
v_ellipse (VDI 11, GDP 5) 367 
v_ellpie (VDI 11, GDP 7) 371 
v__enter_cur (VDI 5, Escape 3) 484 
v_escape2000 (VDI 5, Escape 2000) 531 
v_exit_cur (VDI 5, Escape 2) 483 
vjillarea (VDI 9) 353 
v_fontinit (VDI 5, Escape 102) 530 
v_form_adv (VDI 5, Escape 20) 501 
v_get_pixel (VDI 105) 283, 423 
v_gtext (VDI 8) 351 
v_hardcopy (VDI 5, Escape 17) 498 
v_hide_c (VDI 123) 447 
vJustified (VDI 11, GDP 10) 375 
v_meta_extents (VDI 5, Escape 98) 324, 521 
v_offset (VDI 5, Escape 101) 529 
v_opnvwk (VDI 100) 121, 337 
v_opnwk (VDI 1) 308, 325, 330,456, 

539 

v_output_window (VDI 5, Escape 21) 502 
v_pieslice (VDI 11, GDP 3) 363 
v_pline (VDI 6) 347 
v_pmarker (VDI 7) 349 
v_rbox (VDI 11, GDP 8) 373 
v_rfbox (VDI 11, GDP 9) 374 
v_rmcur (VDI 5, Escape 19) 500 
v.rvoff (VDI 5, Escape 14) 495 
v_rvon (VDI 5, Escape 13) 494 
v_show_c (VDI 122) 317,446 
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v.sound (VDI5, Escape 61) 511 
v_updwk (VDI4) 341 
v_write_meta (VDI 5, Escape 99) 523 
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w 

WAIT (2) 644 
Warmstart 60 
WC_BORDER (0) 693 
WC_WORK (1) 693 
WD1772 956 
Wechselplatte 32, 34, 1114 
Werkzeugleiste 755 
WF_COLOR (18) 688 
WF_CURRXYWH (5) 683,687 
WF_CXYWH (5) 684 
WF_DCOLOR (19) 688 
WFJFIRSTXYWH(ll) 683 
WF_FULLXYWH (7) 683 
WF_FYXWH (7) 684 
WF_HSLIDE (8) 683,687 
WFJHSLSIZE (15) 684,687 
WF_INFO (3) 687 
WF_NAME (2) 687 
WF_NEWDESK (14) 687 
WF_NEXTXYWH (12) 683 
WF_PREVXYWH (6) 683 
WF_PXYWH (6) 684 
WF_SCREEN (17) 684 
WF_SIZTOP (19) 687 
WFJTATTRB (18) 687 
WF_TOP (10) 683,687 
WFJVSLIDE (9) 683,687 
WF_VSLSIZE (16) 684,687 
WF_WORKXYWH (4) 683 
WF_WXYWH (4) 684 
WHITE (0) 558 
WHITEBAK (0x0040) 558 
Wiederholrate 131 
Wildcards 245 

Wilde, Kim: “Love moves” 23 
WIND_CALC (AES 108) 581,692 
WIND_CLOSE (AES 102) 582, 680 
WIND_CREATE (AES 100) 582,677, 679 
WINDJDELETE (AES 103) 582, 680 f. 
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WIND_FIND (AES 106) 551,689 
WIND_GET (AES 104) 581,682 
WIND_NEW (AES 109) 694 
WIND_OPEN (AES 101) 582, 679 f. 

WIND SET (AES 105) 535, 679, 686 
WIND_UPDATE (AES 107) 594, 690 
WM_ARROWED (24) 545 
WM_CLOSED 720,732,739 
WM_CLOSED (22) 545 
WM_FULLED (23) 545 
WMJHSLID (25) 545 
WM_MOVED (28) 546 
WM_NEWTOP (29) 546 
WMJR.EDRAW (20) 544, 597,739 
WM_SIZED (27) 546 
WM_TOPPED (21) 545 
WM_UNTOPPED (30) 546 
WM_VSLID (26) 546 
work area 578 

Workstation 276, 330, 336 f., 339 ff., 666 

Workstation, virtuelle 277 

Wortlängenzähler (MFP-USART) 899 

Wortzugriff (CPU) 794 

Wrap at end of line (VT52 ESC v) 9 

WRITE (SCSI) 1102 

Write character to Standard AUX: 208 

Write character to Standard output 211 

Write character to Standard PRN: 217 

Write Data (FDC) 952 

Write gate (FDC) 951,969 

WRITE METAFILE ITEM (VDI5, Escape 99) 523 

Write protect (FDC) 952, 968 

WRITE SECTOR(ACSI) 995 

WRITE SECTOR (FDC) 968 

Write String to Standard output 214 

Write to file 249 

WRITE TRACK (FDC) 970 

Writing Mode 377 

WYSIWYG 746,764 
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X 


X-Count-Register (BUTTER, Adr. 

$FF 8A36) 847 
XBRA 16,82,167 
Xbtimer (XBIOS 31) 157 
xconin ($53E) 6, 70 
xconout ($57E) 6,71 
xconstat ($5 IE) 6, 70, 98 
XCONTROL 580,688,717 
xcostat ($55E) 6,71 
XCPB 724 f. 

Xform, do 739 
XGen_Alert 741 
XGM-Partition 29 
XGRF_2BOX (AES 131) 714 
XGRF_STEPCALC (AES 130) 712 
XOFF-/XON—Zeichen 904 
XON/XOFF-Betrieb 127 
XOR 418 

XPEN (STE, Adr. $FF 9220) 1290 
XSINT (STE-Sound) 1299 
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Y 

Y-Count-Register (BUTTER, Adr. 

SFF8A38) 847 
YELLOW (6) 558 
YM 2149 (PSG) 859 
YPEN (STE, Adr. $FF 9222) 1290 


Z 


Zahlenformate (68882) 1023 
Zeichen (MIDI) 919 
Zeichenausgabe (par. Schnittstelle) 909 
Zeichenlänge (MFP-USART) 897 
Zeichenorientierte Steuerungsverfahren 1137 
Zeichensatz 287, 316,402, 472, 477, 530 
Zeichensatzformat 289 
Zeichensatznamen 292 
Zeit 129,231,271,273 
Zentraleinheit 787, 793 
Zwischenablage 572, 670 ff., 751 
Zyklische Blockprüfung (Disk) 949 
Zylinder (ACSI) 997 
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